Kort svar

En browser kan bruge et klientcertifikat til mTLS, hvis certifikatet (med dets private nøgle) er installeret i operativsystemets eller browserens certifikatlager. Når en server kræver et klientcertifikat, viser browseren en prompt, hvor brugeren vælger hvilket certifikat der skal sendes. Det giver stærk, phishing-resistent autentificering — men installationsbøvlet og prompten gør det upraktisk til store, anonyme brugerbaser. Derfor bruges det mest internt og til adgang med høj sikkerhed.

Formatet: .p12 / PFX

For at en browser kan præsentere et klientcertifikat, skal den have både certifikatet og den private nøgle. Det leveres typisk som en PKCS#12-fil (.p12 eller .pfx), beskyttet af en adgangskode. Du bygger den fra en separat nøgle og certifikat:

openssl pkcs12 -export \
  -inkey client.key \
  -in client.crt \
  -certfile ca.crt \
  -out client.p12 \
  -name "Alice - Internal Portal"

-certfile ca.crt inkluderer CA'en i bundtet, så kæden følger med. Brugeren importerer derefter .p12-filen i sit certifikatlager (macOS Keychain, Windows Certificate Store eller browserens egen indstilling).

Hvad brugeren faktisk oplever

Når brugeren besøger en mTLS-beskyttet side, sker dette:

  1. Serveren sender en CertificateRequest som led i handshaken.
  2. Browseren finder de installerede certifikater, hvis udsteder matcher serverens accepterede CA'er.
  3. Er der mere end ét, viser browseren en dialog hvor brugeren vælger certifikat.
  4. Browseren sender det valgte certifikat, og serveren validerer det.

Vælger brugeren forkert eller har intet matchende certifikat, fejler handshaken — og browseren viser typisk en uhjælpsom fejlside, ikke en login-formular. Det er en stor del af UX-problemet.

Serverkonfigurationen (kort)

Serversiden er identisk med al anden mTLS — du kræver et klientcertifikat valideret mod en CA. For browseradgang sætter man dog ofte optional frem for on, så man kan vise en pæn fejlside i applikationen i stedet for en hård handshake-afvisning:

ssl_client_certificate /etc/ssl/portal/ca.crt;
ssl_verify_client      optional;

location /admin {
    if ($ssl_client_verify != SUCCESS) { return 403; }
    proxy_pass http://portal_backend;
}

Hele opsætningen af serversiden er den samme som i vores mTLS-guide.

UX-faldgruberne

  • Installation er manuel. Hver bruger skal importere en .p12 med en adgangskode — svært at skalere uden device management (MDM).
  • Prompten forvirrer. Mange brugere forstår ikke certifikat-dialogen og vælger forkert eller annullerer.
  • Skift af enhed. Certifikatet sidder på én maskine; brugeren kan ikke logge ind fra en ny enhed uden at geninstallere det.
  • Fornyelse er usynlig. Når certifikatet udløber, holder adgangen op — ofte uden forvarsel til brugeren.

Hvornår giver det mening?

Klientcertifikater i browseren skinner, hvor sikkerheden vejer tungere end bekvemmeligheden, og brugergruppen er afgrænset og styret: interne admin-portaler, B2B-ekstranet, statslige eID-løsninger og maskiner under device management, hvor certifikatet kan udrulles automatisk. Til store, åbne brugerbaser er token- eller passkey-baseret login næsten altid en bedre vej — sammenlign med mTLS vs OAuth2.

Når brugeradgang afhænger af et certifikat

Det subtile ved browser-mTLS er, at brugernes adgang nu hænger på et certifikats udløbsdato. Når et klientcertifikat — eller den CA der udstedte det — udløber, mister brugerne adgang på én gang, og fejlen ligner alt muligt andet. CertControl overvåger både server- og klientcertifikater samt jeres interne CA'er, sporer hver udløbsdato og advarer i god tid, så et glemt certifikat ikke spærrer jeres brugere ude. Forstå hvor det hører hjemme i mTLS og Zero Trust.

Ofte stillede spørgsmål

Hvad er en .p12-fil?

En PKCS#12-fil der bundter et certifikat sammen med dets private nøgle (og evt. CA-kæden), beskyttet af en adgangskode. Det er det format browsere og operativsystemer importerer klientcertifikater i.

Hvorfor viser browseren en dialog der spørger om certifikat?

Fordi serveren har krævet et klientcertifikat (sendt en CertificateRequest), og browseren fandt et eller flere matchende certifikater i lageret. Dialogen lader brugeren vælge hvilket der skal sendes.

Kan jeg bruge samme klientcertifikat på flere enheder?

Teknisk ja, ved at importere samme .p12 på hver enhed, men det spreder den private nøgle og svækker sikkerheden. Best practice er ét certifikat pr. enhed, ofte udrullet via device management.

Er klientcertifikater i browsere bedre end et login?

De er stærkere mod phishing og credential-tyveri, men dårligere til UX og skalering. Til en lille, styret brugergruppe kan de være bedre; til en stor, åben brugerbase er moderne login (passkeys, OAuth) som regel mere praktisk.

Hvad sker der når klientcertifikatet udløber?

Brugeren mister adgang, og handshaken fejler — typisk uden en venlig forklaring. Derfor bør udløb på klientcertifikater overvåges aktivt, ikke opdages når en bruger pludselig er låst ude.

Se platformen Book demo