X.509

X.509
Informationsteknik - Öppen systemsammankoppling - Katalogen: ramverk för offentliga nyckel och attributcertifikat
Status Gäller (rekommendation)
Först publicerad 1,0 den 25 november 1988 ; 34 år sedan ( 25-11-1988 )
Senaste versionen
9.1 14 oktober 2021 ; 17 månader sedan ( 2021-10-14 )
Organisation ITU-T
Utskott ITU-T studiegrupp 17
Serier X
Basstandarder ASN.1
Relaterade standarder ISO/IEC 9594-8:2020, X.500
Domän Kryptografi
Hemsida www .itu .int /rec /T-REC-X .509

Inom kryptografi är X.509 en standard för International Telecommunication Union (ITU) som definierar formatet för certifikat för publika nyckel . X.509-certifikat används i många Internetprotokoll, inklusive TLS/SSL , som är grunden för HTTPS , det säkra protokollet för att surfa på webben . De används också i offlineapplikationer, som elektroniska signaturer .

Ett X.509-certifikat binder en identitet till en offentlig nyckel med hjälp av en digital signatur. Ett certifikat innehåller en identitet (ett värdnamn, en organisation eller en individ) och en offentlig nyckel ( RSA , DSA , ECDSA , ed25519 , etc.), och är antingen signerat av en certifikatutfärdare eller är självsignerat. När ett certifikat är signerat av en betrodd certifikatutfärdare, eller valideras på annat sätt, kan någon som innehar det certifikatet använda den offentliga nyckel som det innehåller för att upprätta säker kommunikation med en annan part, eller validera dokument digitalt signerade med motsvarande privata nyckel .

X.509 definierar även listor för återkallelse av certifikat , som är ett sätt att distribuera information om certifikat som har bedömts vara ogiltiga av en undertecknande myndighet, samt en valideringsalgoritm för certifieringsväg , som tillåter att certifikat signeras av mellanliggande CA-certifikat, vilket är i sin tur undertecknade av andra certifikat och når så småningom ett förtroendeankare .

X.509 definieras av International Telecommunications Unions "Standardization Sector" ( ITU-T :s SG17 ), i ITU-T Study Group 17 och är baserad på ASN.1 , en annan ITU-T-standard.

Historia och användning

X.509 utfärdades ursprungligen den 3 juli 1988 och påbörjades i samband med X.500 -standarden. De första uppgifterna var att ge användare säker åtkomst till informationsresurser och undvika en kryptografisk man-i-mitten-attack . Det förutsätter ett strikt hierarkiskt system av certifikatutfärdare (CA) för att utfärda certifikaten. Detta står i kontrast till web of trust -modeller, som PGP , där vem som helst (inte bara speciella certifikatutfärdare) kan underteckna och därmed intyga giltigheten av andras nyckelcertifikat.

  Version 3 av X.509 inkluderar flexibiliteten att stödja andra topologier som broar och maskor . Det kan användas i en peer-to-peer, OpenPGP -liknande nät av förtroende, [ citat behövs ] men användes sällan på det sättet från och med 2004. X.500-systemet har bara implementerats av suveräna nationer [ vilka ? ] i syfte att uppfylla fördragsuppfyllelse för statlig identitetsinformation, och IETF: s arbetsgrupp för Public-Key Infrastructure (X.509) (PKIX) har anpassat standarden till den mer flexibla organisationen av Internet. Faktum är att termen X.509-certifikat vanligtvis syftar på IETF:s PKIX-certifikat och CRL -profil för X.509 v3-certifikatstandarden, som specificeras i RFC 5280 , vanligen kallad PKIX for Public Key Infrastructure (X.509) .

Ett tidigt problem med Public Key Infrastructure (PKI) och X.509-certifikat var det välkända problemet med "vilken katalog". Problemet är att klienten inte vet var den ska hämta saknade mellancertifikat eftersom den globala X.500-katalogen aldrig förverkligades. Problemet mildrades genom att inkludera alla mellanliggande certifikat i en begäran. Till exempel skickade tidiga webbservrar bara webbserverns certifikat till klienten. Klienter som saknade ett mellanliggande CA-certifikat eller var de kunde hittas kunde inte bygga en giltig sökväg från CA till serverns certifikat. För att komma runt problemet skickar webbservrar nu alla mellanliggande certifikat tillsammans med webbserverns certifikat.

Medan PKIX hänvisar till IETF:s eller Internets PKI-standard, finns det många andra PKI:er med olika policyer. Till exempel har den amerikanska regeringen sin egen PKI med sina egna policyer, och CA/Browser Forum har sin egen PKI med sina egna policyer. Den amerikanska regeringens PKI är en enorm bok på över 2500 sidor. Om en organisations PKI avviker för mycket från den för IETF eller CA/Browser Forum, riskerar organisationen att förlora interoperabilitet med vanliga verktyg som webbläsare , cURL och Wget . Till exempel, om en PKI har en policy att endast utfärda certifikat på måndag, kommer vanliga verktyg som cURL och Wget inte att tillämpa policyn och tillåta ett certifikat som utfärdas på en tisdag.

Certifikat

X.509-certifikat binder en identitet till en offentlig nyckel med hjälp av en digital signatur. I X.509-systemet finns två typer av certifikat. Det första är ett CA-certifikat. Det andra är ett slutenhetscertifikat. Ett CA-certifikat kan utfärda andra certifikat. Det självsignerade CA-certifikatet på högsta nivån kallas ibland rot-CA-certifikatet. Andra CA-certifikat kallas mellanliggande CA eller underordnade CA-certifikat. Ett slutenhetscertifikat identifierar användaren, som en person, organisation eller företag. Ett slutenhetscertifikat kan inte utfärda andra certifikat. Ett slutenhetscertifikat kallas ibland ett bladcertifikat eftersom inga andra certifikat kan utfärdas under det.

En organisation som vill ha ett signerat certifikat begär ett från en CA med ett protokoll som Certificate Signing Request (CSR) , Simple Certificate Enrollment Protocol (SCEP) eller Certificate Management Protocol (CMP) . Organisationen genererar först ett nyckelpar , håller den privata nyckeln hemlig och använder den för att signera CSR. CSR innehåller information som identifierar sökanden och sökandens publika nyckel som används för att verifiera signaturen på CSR - och det Distinguished Name (DN) som är unikt för personen, organisationen eller verksamheten. CSR kan åtföljas av andra referenser eller identitetsbevis som krävs av certifikatutfärdaren.

CSR kommer att valideras med hjälp av en Registration Authority (RA), och sedan kommer certifieringsmyndigheten att utfärda ett certifikat som binder en offentlig nyckel till ett särskilt framstående namn . Rollerna registreringsmyndighet och certifieringsmyndighet är vanligtvis separata affärsenheter under arbetsuppdelning för att minska risken för bedrägerier.

En organisations betrodda rotcertifikat kan distribueras till alla anställda så att de kan använda företagets PKI-system. [ citat behövs ] Webbläsare som Internet Explorer , Firefox , Opera , Safari och Chrome levereras med en förutbestämd uppsättning rotcertifikat förinstallerade, så SSL- certifikat från större certifikatmyndigheter kommer att fungera direkt; i själva verket bestämmer webbläsarens utvecklare vilka CA:er som är betrodda tredje parter för webbläsarens användare. [ citat behövs ] Till exempel tillhandahåller Firefox en CSV- och/eller HTML-fil som innehåller en lista över inkluderade certifikatutfärdare.

  X.509 och RFC 5280 inkluderar även standarder för implementeringar av CRL ( Certificate Revocation List) . Ett annat IETF -godkänt sätt att kontrollera ett certifikats giltighet är OCSP ( Online Certificate Status Protocol) . Firefox 3.0 aktiverade OCSP-kontroll som standard, liksom versioner av Windows från åtminstone Vista och senare.

Ett certifikats struktur

Strukturen som förutses av standarderna uttrycks i ett formellt språk, Abstrakt syntaxnotation 1 (ASN.1).

Strukturen för ett X.509 v3 digitalt certifikat är följande:

  • Certifikat
    • Versionsnummer
    • Serienummer
    • Signaturalgoritm-ID
    • Emittentens namn
    • Giltighetsperiod
      • Inte före
      • Inte efter
    • Ämnesnamn
    • Ämnesinformation om offentlig nyckel
      • Public Key Algoritm
      • Offentlig nyckel för ämne
    • Utfärdarens unika identifierare (valfritt)
    • Unik identifierare för ämne (valfritt)
    • Tillägg (valfritt)
      • ...
  • Algoritm för certifikatsignatur
  • Certifikats signatur

Fältet Extensions, om det finns, är en sekvens av en eller flera certifikattillägg. Varje tillägg har sitt eget unika ID, uttryckt som objektidentifierare (OID) , som är en uppsättning värden, tillsammans med antingen en kritisk eller icke-kritisk indikation. Ett certifikatanvändande system måste avvisa certifikatet om det stöter på en kritisk tillägg som det inte känner igen, eller en kritisk tillägg som innehåller information som det inte kan bearbeta. En icke-kritisk förlängning kan ignoreras om den inte känns igen, men måste bearbetas om den känns igen.

  Strukturen för version 1 anges i RFC 1422 .

ITU-T introducerade unika identifierare för utfärdare och subjekt i version 2 för att tillåta återanvändning av utfärdaren eller ämnesnamnet efter en tid. Ett exempel på återanvändning är när en CA går i konkurs och dess namn raderas från landets offentliga lista. Efter en tid kan en annan CA med samma namn registrera sig, även om den inte är relaterad till den första. IETF rekommenderar dock att inga utfärdar- och ämnesnamn återanvänds. Därför är version 2 inte allmänt distribuerad på Internet. [ citat behövs ]

Tillägg introducerades i version 3. En CA kan använda tillägg för att utfärda ett certifikat endast för ett specifikt ändamål (t.ex. endast för att signera digitala objekt) .

  I alla versioner måste serienumret vara unikt för varje certifikat utfärdat av en specifik CA (som nämns i RFC 5280 ).

Tillägg som informerar om en specifik användning av ett certifikat

  RFC 5280 (och dess föregångare) definierar ett antal certifikattillägg som anger hur certifikatet ska användas. De flesta av dem är bågar från joint-iso-ccitt(2) ds(5) id-ce(29) OID. Några av de vanligaste, definierade i avsnitt 4.2.1, är:

  • Grundläggande begränsningar, { id-ce 19 } , används för att indikera om certifikatet är ett CA-certifikat och kan certifiera eller utfärda andra certifikat. En begränsning kan markeras som kritisk. Om en begränsning markeras som kritisk måste en agent misslyckas med att behandla certifikatet om agenten inte förstår begränsningen. En agent kan fortsätta att bearbeta en icke-kritisk begränsning som den inte förstår.
  • Nyckelanvändning, { id-ce 15 } , tillhandahåller en bitmapp som specificerar de kryptografiska operationerna som kan utföras med den publika nyckeln som finns i certifikatet; det kan till exempel indikera att nyckeln ska användas för signaturer men inte för kryptering.
  • Utökad nyckelanvändning, { id-ce 37 } , används, vanligtvis på ett bladcertifikat, för att indikera syftet med den publika nyckeln som finns i certifikatet. Den innehåller en lista över OID, som var och en indikerar en tillåten användning. Till exempel { id-pkix 3 1 } att nyckeln kan användas på serveränden av en TLS- eller SSL-anslutning; { id-pkix 3 4 } indikerar att nyckeln kan användas för att skydda e-post.

I allmänhet när RFC 5280 används, om ett certifikat har flera tillägg som begränsar dess användning, måste alla begränsningar vara uppfyllda för att en given användning ska vara lämplig. RFC ger det specifika exemplet på ett certifikat som innehåller både keyUsage och extendedKeyUsage: i det här fallet måste båda bearbetas och certifikatet kan endast användas om båda tilläggen är konsekventa när det gäller att specificera användningen av ett certifikat. Till exempel NSS båda tilläggen för att specificera certifikatanvändning.

Utökade valideringscertifikat

Certifieringsmyndigheter som verkar under CA/Browser Forums PKI utfärdar certifikat med olika nivåer av validering. De olika valideringarna ger olika nivåer av garantier för att ett certifikat representerar vad det ska. Till exempel kan en webbserver valideras på den lägsta nivån av garantier med hjälp av ett e-postmeddelande som heter Domain Validation (DV) . Eller så kan en webbserver valideras på en högre nivå av garantier med mer detaljerade metoder som kallas Extended Validation (EV) .

I praktiken betyder ett DV-certifikat att ett certifikat utfärdades för en domän som example.com efter att någon svarat på ett e-postmeddelande som skickats till [email protected] . Ett EV-certifikat betyder att ett certifikat har utfärdats för en domän som example.com och ett företag som Exempel, LLC är ägare till domänen och ägaren har verifierats av bolagsordningen .

Utökad validering lägger inte till några ytterligare säkerhetskontroller, så den säkra kanaluppställningen med ett EV-certifikat är inte "starkare" än en kanaluppsättning med en annan valideringsnivå som DV.

Utökad validering signaleras i ett certifikat med X.509 v3-tillägg. Varje CA använder en annan objektidentifierare (OID) för att hävda utökad validering. Det finns inget enskilt OID som indikerar utökad validering, vilket komplicerar användaragentprogrammering. Varje användaragent måste ha en lista över OID som indikerar utökad validering.

CA/Browser Forums PKI känner igen utökad validering och många webbläsare ger visuell feedback till användaren för att indikera att en webbplats tillhandahåller ett EV-certifikat. Andra PKI:er, som Internets PKI (PKIX), lägger ingen särskild vikt vid utökad validering. Verktyg som använder PKIX-policyer, som cURL och Wget, behandlar helt enkelt ett EV-certifikat som vilket annat certifikat som helst.

Säkerhetsexperten Peter Gutmann säger att CA:s skapade EV-certifikat för att återställa vinstnivåerna efter att Race to the Bottom skar i vinster. Under kapplöpningen mot botten sänkte CA:s priser för att locka konsumenter att köpa deras certifikat. Som ett resultat minskade vinsterna och CA:er sänkte nivån av validering de utförde till den grad att det nästan inte fanns några garantier för ett certifikat.

Certifikatfilnamnstillägg

Det finns flera vanliga filnamnstillägg för X.509-certifikat. Tyvärr används vissa av dessa tillägg även för annan data som privata nycklar.

  • .pem – ( Sekretessförstärkt elektronisk post ) Base64 -kodat DER- certifikat, inneslutet mellan -----BEGIN CERTIFICATE----- och -----END CERTIFICATE-----
  • .cer , .crt , .der – vanligtvis i binär DER- form, men Base64-kodade certifikat är också vanliga (se .pem ovan)
  • .p7b , .p7c – PKCS#7 SignedDatastruktur utan data, bara certifikat eller CRL (s)
  • .p12 – PKCS#12 , kan innehålla certifikat (offentliga) och privata nycklar (lösenordsskyddad)
  • .pfx – PFX, föregångare till PKCS#12 (innehåller vanligtvis data i PKCS#12-format, t.ex. med PFX-filer genererade i IIS )

PKCS#7 är en standard för att signera eller kryptera (officiellt kallat "omslutande") data. Eftersom certifikatet behövs för att verifiera signerade data är det möjligt att inkludera dem i SignedData-strukturen. En .P7C- fil är en degenererad SignedData-struktur, utan några data att signera. [ citat behövs ]

PKCS#12 har utvecklats från standarden för utbyte av personlig information (PFX) och används för att utbyta offentliga och privata objekt i en enda fil. [ citat behövs ]

Certifikatkedjor och korscertifiering

  En certifikatkedja (se det motsvarande begreppet "certifieringsväg" definierat av RFC 5280 avsnitt 3.2) är en lista över certifikat (vanligtvis börjar med ett slutenhetscertifikat) följt av ett eller flera CA- certifikat (vanligtvis det sista är ett själv -signerat certifikat), med följande egenskaper:

  1. Utfärdaren av varje certifikat (förutom det sista) matchar Ämnet för nästa certifikat i listan
  2. Varje certifikat (förutom det sista) signeras av den hemliga nyckeln som motsvarar nästa certifikat i kedjan (dvs. signaturen för ett certifikat kan verifieras med den publika nyckeln som finns i följande certifikat)
  3. Det sista certifikatet i listan är ett förtroendeankare : ett certifikat som du litar på eftersom det levererades till dig genom något pålitligt förfarande

Certifikatkedjor används för att kontrollera att den publika nyckeln (PK) som finns i ett målcertifikat (det första certifikatet i kedjan) och andra data som finns i det faktiskt tillhör dess ämne. För att säkerställa detta verifieras signaturen på målcertifikatet genom att använda PK:n som finns i följande certifikat, vars signatur verifieras med nästa certifikat, och så vidare tills det sista certifikatet i kedjan nås. Eftersom det sista certifikatet är ett förtroendeankare, kommer framgångsrikt att nå det att bevisa att målcertifikatet kan litas på.

  Beskrivningen i föregående stycke är en förenklad vy av valideringsprocessen för certifieringsvägen enligt definitionen i RFC 5280 avsnitt 6, som inbegriper ytterligare kontroller, såsom att verifiera giltighetsdatum på certifikat, slå upp CRL:er osv.

Exempel 1: Korscertifiering mellan två PKI:er
Exempel 2: CA-certifikatförnyelse

När man undersöker hur certifikatkedjor byggs upp och valideras är det viktigt att notera att ett konkret certifikat kan ingå i väldigt olika certifikatkedjor (alla giltiga). Detta beror på att flera CA-certifikat kan genereras för samma ämne och publika nyckel, men signeras med olika privata nycklar (från olika CA eller olika privata nycklar från samma CA). Så även om ett enda X.509-certifikat bara kan ha en utfärdare och en CA-signatur, kan det vara giltigt länkat till mer än ett certifikat, vilket skapar helt olika certifikatkedjor. Detta är avgörande för korscertifiering mellan PKI:er och andra applikationer. Se följande exempel:

Exempel

I dessa diagram:

  • Varje ruta representerar ett certifikat, med dess ämne i fetstil
  • A → B betyder "A är signerad av B" (eller, mer exakt, "A är signerad av den hemliga nyckeln som motsvarar den publika nyckeln som finns i B").
  • Certifikat med samma färg (som inte är vita/transparenta) innehåller samma publika nyckel

Exempel 1: Korscertifiering på root Certification Authority (CA) nivå mellan två PKI:er

För att hantera att användarcertifikat som finns i PKI 2 (som "Användare 2") är betrodda av PKI 1, genererar CA1 ett certifikat (cert2.1) som innehåller den publika nyckeln för CA2. Nu har både "cert2 och cert2.1 (i grönt) samma ämne och publik nyckel, så det finns två giltiga kedjor för cert2.2 (användare 2): "cert2.2 → cert2" och "cert2.2 → cert2. 1 → cert1".

På liknande sätt kan CA2 generera ett certifikat (cert1.1) som innehåller den publika nyckeln för CA1 så att användarcertifikat som finns i PKI 1 (som "Användare 1") är betrodda av PKI 2.

Exempel 2: CA-certifikatförnyelse

Förstå konstruktion av certifieringsvägar (PDF) . PKI-forum. September 2002. För att möjliggöra en elegant övergång från det gamla signeringsnyckelparet till det nya signeringsnyckelparet bör CA utfärda ett certifikat som innehåller den gamla offentliga nyckeln signerad av den nya privata signeringsnyckeln och ett certifikat som innehåller den nya offentliga nyckeln signerad med den gamla privata signeringsnyckeln. Båda dessa certifikat är självutfärdade, men inget är självsignerat . Observera att dessa är utöver de två självsignerade certifikaten (ett gammalt, ett nytt).

Eftersom både cert1 och cert3 innehåller samma publika nyckel (den gamla) finns det två giltiga certifikatkedjor för cert5: "cert5 → cert1" och "cert5 → cert3 → cert2", och analogt för cert6. Detta gör att gamla användarcertifikat (som cert5) och nya certifikat (som cert6) kan lita på likgiltigt av en part som har antingen det nya rot-CA-certifikatet eller det gamla som förtroendeankare under övergången till de nya CA-nycklarna.

Exempel på X.509-certifikat

Detta är ett exempel på ett avkodat X.509-certifikat som tidigare användes av wikipedia.org och flera andra Wikipedia-webbplatser. Den utfärdades av GlobalSign , som anges i fältet Emittent. Dess Ämnefält beskriver Wikipedia som en organisation, och dess Subject Alternative Name (SAN)-fält för DNS beskriver värdnamnen för vilka den kan användas. Fältet Subject Public Key Info innehåller en ECDSA- nyckel, medan signaturen längst ned genererades av GlobalSigns privata RSA -nyckel. (Signaturerna i dessa exempel är trunkerade.)

Slutenhetscertifikat 

Certifikat: Data: Version: 3 (0x2) Serienummer: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Signaturalgoritm: sha256WithRSAEncryption Utfärdare: C=BE, O=GlobalSign nv -sa, CN=GlobalSign organisationsvalidering CA - SHA256 - G2 Giltighet inte före: 21 nov 08:00:00 2016 GMT Ej efter : 22 nov 07:59:59 2017 GMT Ämne: C=US, ST=Kalifornien, L= San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org Ämne Public Key Info: Public Key Algoritm: id-ecPublicKey Public-Key: (256 bitar) pub: 00:c9:22:69:31: 8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: 9d:3b:ef ASN1 OID: prime256v1 NIST-KURVA: P-256 X509v3-tillägg: X509v3 Nyckelanvändning: kritisk digital signatur, nyckelavtal Myndighetsinformation Åtkomst: CA-utfärdare - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r .crt OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2 X509v3 Certifikatpolicyer: Policy: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Policy: 2.23. 140.1.2.2 X509v3 Grundläggande begränsningar: CA:FALSE X509v3 CRL-distributionspunkter: Fullständigt namn: URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Alternativt ämnesnamn: DNS:*.wikipedia:.org *.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS: *.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS: *.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata. org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks. org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org X509v3 Extended Key Using: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Key Identifier: 28:2A:26:2A:57:8B:3B CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53: 1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Signaturalgoritm: sha256WithRSAencryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18 :5e:30:54:23:35: ...

För att validera detta slutenhetscertifikat behöver man ett mellancertifikat som matchar dess utfärdare och auktoritetsnyckelidentifierare:

Emittent C=BE, O=GlobalSign nv-sa, CN=GlobalSign organisationsvalidering CA - SHA256 - G2
Behörighetsnyckelidentifierare 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

I en TLS-anslutning skulle en korrekt konfigurerad server tillhandahålla intermediären som en del av handskakningen. Det är dock också möjligt att hämta det mellanliggande certifikatet genom att hämta URL:en för "CA Issuers" från slutenhetscertifikatet.

Mellancertifikat

Detta är ett exempel på ett mellanliggande certifikat som tillhör en certifikatutfärdare . Detta certifikat signerade slutenhetscertifikatet ovan och signerades av rotcertifikatet nedan. Observera att ämnesfältet för detta mellanliggande certifikat stämmer överens med utfärdarfältet för slutenhetscertifikatet som det undertecknade. Dessutom matchar fältet "ämnesnyckelidentifierare" i mellanliggande fältet "behörighetsnyckelidentifierare" i slutenhetscertifikatet.

Rotcertifikat

Detta är ett exempel på ett självsignerat rotcertifikat som representerar en certifikatutfärdare . Dess utfärdare och ämnesfält är desamma, och dess signatur kan valideras med sin egen publika nyckel. Validering av förtroendekedjan måste sluta här. Om det validerande programmet har detta rotcertifikat i sitt förtroendelager, kan slutenhetscertifikatet anses vara betrodd för användning i en TLS-anslutning. I annat fall anses slutenhetscertifikatet vara otillförlitligt. 

Certifikat: Data: Version: 3 (0x2) Serienummer: 04:00:00:00:00:01:15:4b:5a:c3:94 Signaturalgoritm: sha1WithRSAEncryption Utgivare: C=BE, O=GlobalSign nv-sa , OU=Root CA, CN=GlobalSign Root CA Giltighet inte före: 1 sep 12:00:00 1998 GMT Inte efter : Jan 28 12:00:00 2028 GMT Ämne: C=BE, O=GlobalSign nv-sa, OU =Root CA, CN=GlobalSign Root CA Ämne Public Key Info: Public Key Algoritm: rsaEncryption Public-Key: (2048 bitar) Modul: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a :7e:fb:f1:8b: ... Exponent: 65537 (0x10001) X509v3-tillägg: X509v3 Nyckelanvändning: kritisk certifikattecken, CRL-tecken X509v3 Grundläggande begränsningar: kritisk CA:TRUE X509v3 Ämnesnyckelidentifierare: 660:7B: 1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signaturalgoritm: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0 :8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...

säkerhet

Det finns ett antal publikationer om PKI-problem av Bruce Schneier , Peter Gutmann och andra säkerhetsexperter.

Arkitektoniska svagheter

  • Användning av blockeringslistor av ogiltiga certifikat (med CRL:er och OCSP ),
    • Om klienten endast litar på certifikat när CRL:er är tillgängliga, förlorar de offline-förmågan som gör PKI attraktiv. Så de flesta klienter litar på certifikat när CRL:er inte är tillgängliga, men i så fall kan en angripare som kontrollerar kommunikationskanalen inaktivera CRL:erna. Adam Langley från Google har sagt att soft-fail CRL-kontroller är som ett säkerhetsbälte som fungerar förutom när du råkar ut för en olycka.
  • CRL är särskilt ett dåligt val på grund av stora storlekar och invecklade distributionsmönster,
  • Tvetydig OCSP-semantik och avsaknad av historisk återkallelsestatus,
  • Återkallelse av rotcertifikat behandlas inte,
  • Aggregeringsproblem : Identitetsanspråk (autenticera med en identifierare), attributanspråk (skicka in en påse med kontrollerade attribut) och policyanspråk kombineras i en enda behållare. Detta väcker frågor om integritet, policykartläggning och underhåll. [ förtydligande behövs ]
  • Delegeringsproblem : CA:er kan inte tekniskt begränsa underordnade CA från att utfärda certifikat utanför en begränsad namnrymd eller attributuppsättning; den här funktionen i X.509 används inte. Därför finns ett stort antal CA på Internet, och att klassificera dem och deras policyer är en oöverstiglig uppgift. Delegering av befogenheter inom en organisation kan inte hanteras alls, som i vanlig affärspraxis.
  • Federationsproblem : Certifikatkedjor som är resultatet av underordnade certifikatutfärdare, bryggcertifikatutfärdare och korssignering gör valideringen komplex och dyr när det gäller behandlingstid. Semantik för vägvalidering kan vara tvetydig. Hierarkin med en betrodd tredje part är den enda modellen. Detta är obekvämt när en bilateral förtroenderelation redan finns på plats.
  • Utfärdande av ett Extended Validation (EV)-certifikat för ett värdnamn hindrar inte utfärdande av ett lägre valideringscertifikat som är giltigt för samma värdnamn, vilket innebär att den högre valideringsnivån för EV inte skyddar mot man-in-the-midten attacker.

Problem med certifieringsmyndigheter

  • Den person eller organisation som köper ett certifikat kommer ofta att använda den billigaste certifikatutfärdaren. Som svar har CA:s sänkt priserna och tagit bort dyrare valideringskontroller i det som kallas Race to the Bottom . Race to the Bottom hanteras delvis av Extended Validation (EV) -certifikat, men förtroendevärdet i säkerhetsexperternas ögon minskar. Enligt Peter Gutmann lägger EV-certifikat inte till några ytterligare säkerhetskontroller. Snarare återställer EV-certifikat bara CA-vinster till nivåer före Race to the Bottom genom att låta en CA ta betalt mer för en tjänst som de borde ha tillhandahållit hela tiden.
  • Certifieringsmyndigheter försöker neka nästan alla garantier till användaren och förlitande parter i deras Certification Practice Statement (CPS) . Till exempel, Apple Inc anger i sin CPS, "I den utsträckning det är tillåtet enligt tillämplig lag, frånsäger sig abonnentavtal, om tillämpligt, garantier från Apple, inklusive alla garantier för säljbarhet eller lämplighet för ett visst ändamål".
  • Enligt Peter Gutmann, "Användare använder ett odefinierat protokoll för certifieringsbegäran för att få ett certifikat som publiceras på en oklar plats i en obefintlig katalog utan några verkliga medel att återkalla det"
  • Liksom alla företag är CA:er föremål för de juridiska jurisdiktioner de verkar inom, och kan vara juridiskt tvingade att äventyra sina kunders och deras användares intressen. Underrättelsebyråer har också använt sig av falska certifikat som utfärdats genom extralegal kompromiss av certifikatutfärdare, såsom DigiNotar , för att utföra man-in-the-middle-attacker . [ citat behövs ] Ett annat exempel är en begäran om återkallelse från den nederländska regeringens CA, på grund av en holländsk lag som antogs 2018, som ger nya befogenheter för den holländska underrättelse- och säkerhetstjänsten

Implementeringsfrågor

Implementeringar lider av designfel, buggar, olika tolkningar av standarder och bristande interoperabilitet mellan olika standarder. Några problem är: [ citat behövs ]

  • Många implementeringar stänger av återkallelsekontroll:
    • Ses som ett hinder, tillämpas inte policyer
    • Om det var aktiverat i alla webbläsare som standard, inklusive kodsignering, skulle det förmodligen krascha infrastrukturen [ citat behövs ]
  • DN:er är komplexa och lite förstådda (brist på kanonisering, internationaliseringsproblem)
  • rfc822Name har två notationer
  • Namn och policybegränsningar stöds knappast
  • Nyckelanvändning ignoreras, första certifikatet i en lista används
  • Genomförande av anpassade OID är svårt
  • Attribut bör inte göras kritiska eftersom det gör att klienter kraschar [ citat behövs ]
  • Ospecificerad längd på attribut leder till produktspecifika gränser
  • Det finns implementeringsfel med X.509 som tillåter t.ex. förfalskade ämnesnamn med hjälp av nollterminerade strängar eller kodinjektionsattacker i certifikat
  • Genom att använda illegala 0x80 vadderade underidentifierare av objektidentifierare , felaktiga implementeringar eller genom att använda heltalsöverflöden av klientens webbläsare, kan en angripare inkludera ett okänt attribut i CSR, som CA kommer att signera, vilket klienten felaktigt tolkar som "CN" (OID) =2.5.4.3). Dan Kaminsky vid den 26:e Chaos Communication Congress "Black OPs of PKI"

Kryptografiska svagheter

Digitala signatursystem är beroende av säkra kryptografiska hashfunktioner för att fungera. När en offentlig nyckelinfrastruktur tillåter användning av en hashfunktion som inte längre är säker, kan en angripare utnyttja svagheter i hashfunktionen för att förfalska certifikat. Specifikt, om en angripare kan producera en hashkollision , kan de övertyga en certifikatutfärdare att signera ett certifikat med ofarligt innehåll, där hashen för detta innehåll är identisk med hashen för en annan, skadlig uppsättning certifikatinnehåll, skapad av angriparen med värderingar som de själva väljer. Angriparen kan sedan lägga till den CA-tillhandahållna signaturen till sitt skadliga certifikatinnehåll, vilket resulterar i ett skadligt certifikat som verkar vara signerat av CA. Eftersom innehållet i det skadliga certifikatet enbart väljs av angriparen, kan de ha andra giltighetsdatum eller värdnamn än det ofarliga certifikatet. Det skadliga certifikatet kan till och med innehålla ett "CA: true"-fält som gör det möjligt att utfärda ytterligare betrodda certifikat.

  • MD2-baserade certifikat användes under lång tid och var sårbara för preimage-attacker . Eftersom rotcertifikatet redan hade en självsignatur kunde angripare använda denna signatur och använda den för ett mellancertifikat.
  • 2005 demonstrerade Arjen Lenstra och Benne de Weger "hur man använder hashkollisioner för att konstruera två X.509-certifikat som innehåller identiska signaturer och som endast skiljer sig åt i de publika nycklarna", uppnått med hjälp av en kollisionsattack på MD5 - hashfunktionen.
  • 2008 presenterade Alexander Sotirov och Marc Stevens på Chaos Communication Congress en praktisk attack som gjorde det möjligt för dem att skapa en oseriös certifikatutfärdare, accepterad av alla vanliga webbläsare, genom att utnyttja det faktum att RapidSSL fortfarande utfärdade X.509-certifikat baserade på MD5.
  • I april 2009 vid Eurocrypt-konferensen presenterade australiensiska forskare vid Macquarie University "Automatic Differential Path Searching for SHA-1 ". Forskarna kunde härleda en metod som ökar sannolikheten för en kollision med flera storleksordningar.
  • I februari 2017 producerade en grupp forskare under ledning av Marc Stevens en SHA-1-kollision, vilket visar SHA-1:s svaghet.

Åtgärder för kryptografiska svagheter

Att utnyttja en hashkollision för att förfalska X.509-signaturer kräver att angriparen kan förutsäga de data som certifikatutfärdaren kommer att signera. Detta kan mildras något genom att CA genererar en slumpmässig komponent i certifikaten den signerar, vanligtvis serienumret. CA /webbläsarforum har krävt serienummerentropi i sitt Baseline Requirements Section 7.1 sedan 2011.

Från och med den 1 januari 2016 förbjuder Baseline Requirements utfärdande av certifikat med SHA-1. Från och med början av 2017 avvisar Chrome och Firefox certifikat som använder SHA-1. Från och med maj 2017 avvisar både Edge och Safari också SHA-1-certifikat. X.509-validatorer som inte är webbläsare avvisar ännu inte SHA-1-certifikat.

PKI-standarder för X.509

  • PKCS7 (Cryptographic Message Syntax Standard — offentliga nycklar med bevis på identitet för signerat och/eller krypterat meddelande för PKI)
  • Transport Layer Security (TLS) och dess föregångare SSL — kryptografiska protokoll för säker internetkommunikation.
  • Online Certificate Status Protocol (OCSP)/Certificate Revocation List (CRL) – detta är för att kontrollera certifikatets återkallelsestatus
  • PKCS12 (Personal Information Exchange Syntax Standard) – används för att lagra en privat nyckel med lämpligt certifikat för offentlig nyckel
  • Byggande av certifieringsvägar — vägledning och rekommendationer för att bygga X.509-certifieringsvägar med publik nyckel inom applikationer (dvs. validering av ett slutenhetscertifikat med ett CA-certifikat)

PKIX arbetsgrupp

  1995 bildade Internet Engineering Task Force i samarbete med National Institute of Standards and Technology arbetsgruppen Public-Key Infrastructure (X.509). Arbetsgruppen, som avslutades i juni 2014, kallas vanligtvis "PKIX". Den producerade RFC:er och annan standarddokumentation om att använda och distribuera X.509 i praktiken. I synnerhet producerade den RFC 3280 och dess efterföljare RFC 5280, som definierar hur X.509 ska användas i Internetprotokoll.

Viktiga protokoll och standarder som använder X.509-certifikat

  TLS/SSL och HTTPS använder RFC 5280- profilen för X.509, liksom S/MIME (Secure Multipurpose Internet Mail Extensions) och EAP-TLS- metoden för WiFi-autentisering. Alla protokoll som använder TLS, som SMTP, POP, IMAP, LDAP, XMPP och många fler, använder i sig X.509.

  IPsec kan använda RFC 4945 -profilen för autentisering av kamrater.

OpenCable -säkerhetsspecifikationen definierar sin egen profil av X.509 för användning inom kabelindustrin.

Enheter som smartkort och TPM har ofta certifikat för att identifiera sig själva eller sina ägare. Dessa certifikat är i X.509-form.

WS -Security- standarden definierar autentisering antingen genom TLS eller genom sin egen certifikatprofil. Båda metoderna använder X.509.

Microsoft Authenticode- kodsigneringssystemet använder X.509 för att identifiera författare till datorprogram.

OPC UA kommunikationsstandard för industriell automation använder X.509.

SSH använder i allmänhet en Trust On First Use- säkerhetsmodell och har inget behov av certifikat. Den populära OpenSSH-implementeringen stöder dock en CA-signerad identitetsmodell baserad på dess eget icke-X.509-certifikatformat.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=X.509&oldid=1144381368 "