{"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/certificate-authority","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/certificate-authority/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/certificate-authority/"},"term":{"en":"Certificate authority (CA)","da":"Certifikatudsteder (CA)"},"aka":{"en":["certification authority"],"da":[]},"domain":["cs"],"cluster":"cryptography","layer":"theory","status":"current","era":1988,"summary":{"en":"A trusted body that checks who someone is and then signs digital certificates vouching that a public key belongs to them.","da":"En betroet instans, der kontrollerer identiteten på en ansøger og signerer digitale certifikater om, hvem en offentlig nøgle tilhører."},"body":{"formal":{"en":"The issuing party in a public key infrastructure. It signs each certificate with its own private key, keeps public lists of certificates it has cancelled before they expire, and is trusted because its root certificate is already stored in browsers and operating systems.","da":"Den udstedende part i en offentlig nøgleinfrastruktur. Den signerer hvert certifikat med sin egen private nøgle, offentliggør lister over certifikater, den har tilbagekaldt før udløb, og nyder tillid, fordi dens rodcertifikat allerede ligger i browsere og styresystemer."},"plain":{"en":"Like the passport office - it checks your papers before issuing a passport, and border guards accept the passport because they trust the office, not because they know you.","da":"Som paskontoret - det tjekker dine papirer, før det udsteder et pas, og grænsevagter godtager passet, fordi de stoler på kontoret, ikke fordi de kender dig."},"inPractice":{"en":"A regional hospital needs a new certificate for its patient portal. The CA checks that the region really controls the web address and signs the certificate, and patients' browsers then open the site without a warning.","da":"Et regionshospital skal have et nyt certifikat til sin patientportal. Udstederen kontrollerer, at regionen faktisk råder over webadressen, og signerer certifikatet, hvorefter patienternes browsere åbner siden uden advarsel."},"whyItMatters":{"en":"The whole chain of trust rests on a small number of issuers; if one is broken into or careless, attackers can get real-looking certificates for sites that are not theirs.","da":"Hele tillidskæden hviler på et lille antal udstedere; bliver der brudt ind hos én af dem, eller er den uforsigtig, kan angribere få ægte udseende certifikater til websteder, der ikke er deres."}},"deepDive":{"en":"Technically a CA is a key pair plus the policy and operations around it. A root CA has a self-signed certificate distributed out of band in trust stores (Mozilla NSS, Apple, Microsoft, the Chrome Root Store); the root key is normally kept offline in an HSM and used only to sign a few intermediate CA certificates carrying basicConstraints cA=TRUE, an optional pathLenConstraint and keyCertSign/cRLSign key usage (RFC 5280 §4.2.1.9, §4.2.1.3). Issuance happens from the intermediates, so a compromised issuing CA can be revoked without replacing the root on billions of devices.\n\nPublicly trusted CAs follow the CA/Browser Forum Baseline Requirements, enforced by browser root programs and checked by annual WebTrust or ETSI EN 319 411 audits. Domain control must be validated with a method from BR §3.2.2.4 (an HTTP token under /.well-known/, a DNS TXT record, the ACME challenges of RFC 8555), CAA records (RFC 8659) must be checked, and since 15 March 2025 validation and CAA results must be corroborated from multiple network perspectives to resist BGP and DNS hijacking. Maximum TLS certificate validity fell from 398 to 200 days on 15 March 2026 and is scheduled to drop to 100 days in March 2027 and 47 days in March 2029 (ballot SC-081), which makes automated renewal effectively mandatory.\n\nA CA also publishes status information: CRLs (RFC 5280 §5) are signed lists of revoked serial numbers, OCSP (RFC 6960) answers per certificate. The Baseline Requirements made OCSP optional in 2024 while keeping CRLs mandatory, and Let's Encrypt among others has since shut its OCSP service down. Browser revocation checking is mostly soft-fail or based on vendor-pushed lists, so short lifetimes increasingly do the real work of revocation.\n\nThe central failure mode is misissuance. DigiNotar was breached in 2011, issued a fraudulent *.google.com certificate used against Iranian users, was removed from every trust store and went bankrupt; Symantec's roots were distrusted in 2018 after repeated violations, and Chrome stopped trusting newly issued Entrust TLS certificates from November 2024. Certificate Transparency (RFC 6962) requires publicly trusted certificates to be logged in append-only logs, so domain owners can detect misissuance. A CA differs from a registration authority, which only vets applicants, and from the PKI as a whole. Private enterprise CAs such as Active Directory Certificate Services are trusted only on managed devices, and misconfigured certificate templates there are a well-known privilege-escalation path.","da":"Teknisk set er en CA et nøglepar plus den politik og drift, der omgiver det. En rod-CA har et selvsigneret certifikat, som distribueres ad anden vej via trust stores (Mozilla NSS, Apple, Microsoft, Chrome Root Store); rodnøglen opbevares normalt offline i en HSM og bruges kun til at signere nogle få mellemliggende CA-certifikater med basicConstraints cA=TRUE, eventuelt pathLenConstraint, og key usage keyCertSign/cRLSign (RFC 5280 §4.2.1.9 og §4.2.1.3). Udstedelsen sker fra de mellemliggende CA'er, så en kompromitteret udstedende CA kan tilbagekaldes, uden at roden skal skiftes på milliarder af enheder.\n\nOffentligt betroede CA'er følger CA/Browser Forums Baseline Requirements, som håndhæves af browsernes rodprogrammer og kontrolleres ved årlige WebTrust- eller ETSI EN 319 411-revisioner. Domænekontrol skal valideres med en metode fra BR §3.2.2.4 (et HTTP-token under /.well-known/, en DNS TXT-post, ACME-udfordringerne i RFC 8555), CAA-poster (RFC 8659) skal tjekkes, og siden 15. marts 2025 skal validering og CAA-resultater bekræftes fra flere netværksperspektiver for at modstå BGP- og DNS-kapring. Den maksimale gyldighed for TLS-certifikater faldt fra 398 til 200 dage den 15. marts 2026 og skal efter planen ned på 100 dage i marts 2027 og 47 dage i marts 2029 (ballot SC-081), hvilket i praksis gør automatisk fornyelse obligatorisk.\n\nEn CA offentliggør også statusoplysninger: CRL'er (RFC 5280 §5) er signerede lister over tilbagekaldte serienumre, OCSP (RFC 6960) svarer pr. certifikat. Baseline Requirements gjorde OCSP valgfrit i 2024, men fastholdt kravet om CRL'er, og bl.a. Let's Encrypt har siden lukket sin OCSP-tjeneste. Browseres tilbagekaldelsestjek er for det meste soft-fail eller bygger på lister, som leverandøren selv distribuerer, så kort levetid gør i stigende grad det egentlige arbejde med tilbagekaldelse.\n\nDen centrale fejltype er fejludstedelse. DigiNotar blev hacket i 2011, udstedte et falsk *.google.com-certifikat, der blev brugt mod iranske brugere, blev fjernet fra alle trust stores og gik konkurs; Symantecs rødder blev afvist i 2018 efter gentagne regelbrud, og Chrome holdt op med at stole på nyudstedte TLS-certifikater fra Entrust fra november 2024. Certificate Transparency (RFC 6962) kræver, at offentligt betroede certifikater logges i append-only-logs, så domæneejere kan opdage fejludstedelse. En CA adskiller sig fra en registreringsinstans (RA), der kun kontrollerer ansøgere, og fra PKI'en som helhed. Private virksomheds-CA'er som Active Directory Certificate Services er kun betroede på administrerede enheder, og forkert konfigurerede certifikatskabeloner dér er en velkendt vej til rettighedseskalering."},"edges":[{"type":"requires","to":"cs/digital-certificate","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/digital-signature","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/identity","confidence":"high","strength":"normal"},{"type":"part-of","to":"cs/public-key-infrastructure","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/tls","why":{"en":"TLS checks the other side's certificate, and that check only means something because a trusted CA signed it.","da":"TLS tjekker modpartens certifikat, og det tjek betyder kun noget, fordi en betroet CA har signeret det."},"confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile","url":"https://www.rfc-editor.org/rfc/rfc5280","tier":"standard","publisher":"IETF"},{"title":"NIST SP 800-32 - Introduction to Public Key Technology and the Federal PKI Infrastructure","url":"https://csrc.nist.gov/pubs/sp/800/32/final","tier":"standard","publisher":"NIST"}],"draft":true}