{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/digital-certificate","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/digital-certificate/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/digital-certificate/"},"term":{"en":"Digital certificate","da":"Digitalt certifikat"},"aka":{"en":["public key certificate","X.509 certificate","SSL certificate"],"da":["certifikat","X.509-certifikat","SSL-certifikat"]},"domain":["cs"],"cluster":"cryptography","layer":"theory","status":"current","era":1988,"summary":{"en":"A signed digital document that ties a public key to a name, such as a website address, so others can trust whose key it is.","da":"Et signeret digitalt dokument, der knytter en offentlig nøgle til et navn, fx en webadresse, så andre kan stole på, hvis nøgle det er."},"body":{"formal":{"en":"A data record, usually in the X.509 format, holding a public key, the identity it belongs to and a validity period, signed by a certificate authority whose own certificate can in turn be checked, forming a chain back to a root the device already trusts.","da":"En datapost, som regel i X.509-format, med en offentlig nøgle, den identitet, den tilhører, og en gyldighedsperiode, signeret af en certifikatudsteder, hvis eget certifikat igen kan tjekkes, så der dannes en kæde tilbage til et rodcertifikat, enheden allerede stoler på."},"plain":{"en":"Like a letter of introduction stamped by an authority both sides trust - the reader accepts the stranger because of the stamp, and only until the date written on it.","da":"Som et anbefalingsbrev stemplet af en myndighed, begge parter stoler på - modtageren godtager den fremmede på grund af stemplet, og kun indtil den dato, der står på brevet."},"inPractice":{"en":"A municipality forgets to renew the certificate for its self-service portal; the next morning citizens' browsers show a full-page warning, and the citizen service desk is flooded with calls.","da":"En kommune glemmer at forny certifikatet til sin selvbetjeningsportal; næste morgen viser borgernes browsere en helsides advarsel, og borgerservice bliver overhældt med opkald."},"whyItMatters":{"en":"Encryption is useless if the private conversation is with the wrong party; certificates are what prove a website or server is the real one.","da":"Kryptering er værdiløs, hvis den fortrolige samtale foregår med den forkerte; certifikater er det, der beviser, at et websted eller en server er den ægte."}},"deepDive":{"en":"An X.509 v3 certificate (ITU-T X.509, first published 1988; profiled for the internet in RFC 5280) is an ASN.1 structure encoded in DER, usually transported base64-wrapped as PEM. Per RFC 5280 §4.1 it consists of tbsCertificate, signatureAlgorithm and signatureValue; the to-be-signed part holds version, serialNumber, signature, issuer, validity (notBefore/notAfter), subject, subjectPublicKeyInfo and extensions. The CA's signature covers the exact DER bytes of tbsCertificate, so any change, even re-encoding, invalidates it. Publicly trusted TLS certificates must have serial numbers with at least 64 bits of CSPRNG output, a defence against the kind of chosen-prefix hash collision that produced a rogue CA certificate from MD5 in 2008.\n\nExtensions carry most of the semantics. subjectAltName (§4.2.1.6) lists the DNS names and IP addresses the certificate is valid for; browsers have ignored the subject Common Name for hostname matching since around 2017 (Chrome 58), so a certificate without SAN fails even if the CN is right. keyUsage and extendedKeyUsage restrict use (serverAuth, clientAuth, codeSigning), basicConstraints separates CA from end-entity certificates, and authorityInfoAccess and cRLDistributionPoints tell the relying party where to fetch the issuer certificate and revocation data. Wildcards match exactly one label: *.example.dk covers www.example.dk but not example.dk or a.b.example.dk.\n\nValidation follows the path-validation algorithm in RFC 5280 §6: build a chain from the leaf through intermediates to a trust anchor, then check each signature, validity period, name and policy constraints, key usage and revocation status. Most real outages are chain-building or lifetime problems: a server that sends only the leaf and omits the intermediate works in browsers that cache or fetch intermediates but fails in curl, Java or IoT clients; an expired intermediate or root breaks clients that have not updated their trust stores. The certificate itself is public; what must be protected is the matching private key, typically delivered alongside in a PKCS#12 (.pfx) file or generated on the server from a CSR (PKCS#10) so it never leaves the machine.\n\nCommon misconceptions: a certificate does not encrypt anything, it authenticates the key used in the TLS handshake; DV, OV and EV differ only in how much identity vetting the CA did, not in cryptographic strength, and browsers no longer show EV prominently. Self-signed certificates provide encryption but no third-party authentication unless the key is pinned or distributed out of band. With TLS certificate lifetimes being cut stepwise from 398 days towards 47 days by 2029, inventory and automated renewal (ACME, RFC 8555) matter more than the choice of CA. Outside the web, the same format is used for client certificates in mutual TLS, S/MIME e-mail, code signing and eIDAS qualified certificates.","da":"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.\n\nUdvidelserne 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.\n\nValidering 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.\n\nTypiske 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."},"edges":[{"type":"requires","to":"cs/public-key-cryptography","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/identity","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/digital-signature","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"implements","to":"security/non-repudiation","confidence":"high","strength":"normal"}],"depth":3,"sources":[{"title":"RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile","tier":"standard"},{"title":"Paar & Pelzl, Understanding Cryptography","tier":"textbook"}],"draft":true}