Digitalt certifikat

Et X.509 v3-certifikat (ITU-T X.509, første gang udgivet i 1988; profileret til internettet i RFC 5280) er en ASN.1-struktur kodet i DER og som regel transporteret base64-indpakket som PEM. Ifølge RFC 5280 §4.1 består det af tbsCertificate, signatureAlgorithm og signatureValue; den del, der signeres, indeholder version, serialNumber, signature, issuer, validity (notBefore/notAfter), subject, subjectPublicKeyInfo og extensions. Udstederens signatur dækker de præcise DER-bytes i tbsCertificate, så enhver ændring, selv en omkodning, gør den ugyldig. Offentligt betroede TLS-certifikater skal have serienumre med mindst 64 bit output fra en CSPRNG, et forsvar mod den slags hashkollision med valgt præfiks, som i 2008 gav et falsk CA-certifikat via MD5.

Udvidelserne bærer det meste af betydningen. subjectAltName (§4.2.1.6) angiver de DNS-navne og IP-adresser, certifikatet gælder for; browsere har ignoreret subject Common Name ved navnematch siden omkring 2017 (Chrome 58), så et certifikat uden SAN fejler, selv om CN er korrekt. keyUsage og extendedKeyUsage begrænser brugen (serverAuth, clientAuth, codeSigning), basicConstraints skelner mellem CA- og slutcertifikater, og authorityInfoAccess og cRLDistributionPoints fortæller den tillidshavende part, hvor udstedercertifikat og tilbagekaldelsesdata hentes. Wildcards matcher præcis ét label: *.example.dk dækker www.example.dk, men ikke example.dk eller a.b.example.dk.

Validering følger algoritmen i RFC 5280 §6: der bygges en kæde fra slutcertifikatet gennem mellemliggende certifikater til et trust anchor, hvorefter hver signatur, gyldighedsperiode, navne- og politikbegrænsning, key usage og tilbagekaldelsesstatus tjekkes. De fleste reelle nedbrud skyldes kædeopbygning eller levetid: en server, der kun sender slutcertifikatet og udelader det mellemliggende, virker i browsere, der cacher eller henter mellemcertifikater, men fejler i curl, Java eller IoT-klienter; et udløbet mellem- eller rodcertifikat knækker klienter, hvis trust store ikke er opdateret. Selve certifikatet er offentligt; det, der skal beskyttes, er den tilhørende private nøgle, som enten leveres sammen med det i en PKCS#12-fil (.pfx) eller genereres på serveren ud fra en CSR (PKCS#10), så den aldrig forlader maskinen.

Typiske misforståelser: et certifikat krypterer ikke noget, det autentificerer den nøgle, der bruges i TLS-håndtrykket; DV, OV og EV adskiller sig kun ved, hvor grundigt udstederen har kontrolleret identiteten, ikke ved kryptografisk styrke, og browsere fremhæver ikke længere EV. Selvsignerede certifikater giver kryptering, men ingen autentificering via tredjepart, medmindre nøglen er pinnet eller distribueret ad anden vej. Når levetiden for TLS-certifikater skæres trinvis ned fra 398 dage mod 47 dage i 2029, betyder overblik over certifikaterne og automatisk fornyelse (ACME, RFC 8555) mere end valget af udsteder. Uden for webben bruges samme format til klientcertifikater i gensidig TLS, S/MIME-mail, kodesignering og kvalificerede certifikater efter eIDAS.