X.509

X.509 er en standard, der specificerer formater for offentlige nøglecertifikater, tilbagekaldelseslister for certifikater, attributter for certifikater og en godkendelsesalgoritme for certificeringssti defineret af International Telecommunication Union (ITU). X.509 etablerer blandt andet et standard elektronisk certifikatformat og en algoritme til validering af certificeringssti. X.509 har også været adskillige RFC'er fra IETF .

X.509 blev oprettet i 1988 som en del af X.500- standarden . Det er baseret på et hierarkisk system af certificeringsmyndigheder , i modsætning til pålidelige netværk (såsom OpenPGP -webværket ), hvor enhver kan underskrive andres certifikater.

Certifikater

I X.509-system, en certificering myndighed tildeler et certifikat binde en offentlig nøgle til en Distinguished Name , hvis format defineres af X.500 anbefaling , eller til et alternativt navn ( Alternativt navn ) såsom '' en e-mail-adresse eller DNS- optage .

Dette certifikat placerer en certificeringsmyndigheds underskrift i det sidste felt. Konkret udføres denne signatur af et kondensat af alle de foregående felter i certifikatet og en kryptering af dette kondensat af certificeringsmyndighedens private nøgle. Enhver med den offentlige nøgle til denne CA kan dekryptere hashen og sammenligne den med deres egen certifikat-hash-beregning. Hvis de to kondensater er identiske, garanterer dette, at certifikatet er intakt, det er ikke blevet ændret. CA's certifikat, der indeholder sin offentlige nøgle, kan igen underskrives af et andet certifikat på højere niveau og danner således en kæde. Øverst i kæden er de vigtigste certifikater : rodcertifikater .

Rodcertifikater er usignerede eller selvsignerede offentlige nøgler, som du stoler på. Software, såsom webbrowsere eller e-mail-klienter, har rodcertifikater fra mange kommercielle eller offentlige certificeringsmyndigheder. Når en browser åbner en sikker forbindelse ( TLS / SSL ) til et websted, der har et certifikat udstedt af en kendt myndighed, betragter den webstedet som sikkert, så længe certificeringsstien er valideret. Skift til sikker tilstand er derefter gennemsigtig.

Hvis softwaren (browser eller andet) ikke kender certificeringsmyndigheden (certifikat genereret og selvsigneret af en person eller certificeringsmyndighed, der endnu ikke er kendt eller frivilligt fjernet fra listen over godkendte myndigheder), foreslår browseren at undersøge certifikatet, så at acceptere eller afvise det i henhold til tilliden til det.

X.509 kan bruges med S / MIME , TLS / SSL , SET og IPsec .

Opbygning af et certifikat

Den originale definition er tilgængelig i RFC  2459 (afsnit 4) eller i den nyeste version ( RFC  5280), som indeholder en specialisering på X.509 til internetapplikationer . Den godkendte del indeholder følgende felter:

Navnene på afsenderen (også underskriver) og indehaveren er X.501 navne, som også kan findes i ISO- og LDAP- mapper . Ovenstående indhold efterfølges af en gentagelse af signaturalgoritmen og selve signaturen.

Intet blandt de obligatoriske felter tillader at skelne en certificeringsmyndighed (en organisation, der udsteder certifikater) fra en simpel indehaver. BasicConstraints- udvidelsen defineret i X.509 version 3 løser denne begrænsning. En anden ufuldkommenhed af samme type er, at kun navnet tillader, at et certifikat knyttes til dets udsteder, mens navnernes unikke egenskaber ikke kan garanteres.

Udvidelser til standard og specifik brug af et certifikat

De RFC  5280 definerer en sum af udvidelser, der angiver den påtænkte anvendelse af certifikatet. Her er de mest almindelige udvidelser:

Generelt, hvis et certifikat har flere udvidelser, der begrænser dets anvendelse, skal alle betingelser være opfyldt for at brugen skal være passende. Den RFC  5280 giver det specifikke eksempel på et certifikat, der indeholder både KeyUsage extendedKeyUsage og, i dette tilfælde de to betingelser skal være opfyldt for certifikatet kan anvendes ifølge påtænkte anvendelser.

Filnavne til certifikater

Her er de almindelige udvidelser af certifikater i X.509-format:

Kædecertificering

En certifikatkæde er en liste over certifikater (startende med en enhed, der skal certificeres, såsom en server), der omfatter en eller flere certificeringsmyndigheder (den sidste er underskrevet af sig selv) med følgende egenskaber:

  1. Underskriveren af ​​hvert certifikat (undtagen det sidste) er efterfølgermyndigheden i kæden
  2. Hvert certifikat (undtagen det sidste) er underskrevet af den private myndigheds private nøgle i kæden (underskriften af ​​et certifikat kan verificeres ved hjælp af myndighedens offentlige nøgle)
  3. Det sidste certifikat på listen er indgangsstedet for tillidskæden, der betragtes som lovligt udstedt

Certifikat kæder bruges til at sikre, at den offentlige nøgle og certifikat data (den 1 m af kæden) svarer til ejeren af det. For at sikre dette verificeres den digitale signatur ved hjælp af den næste enheds offentlige nøgle i kæden, selv underskrevet af den offentlige enheds nøgle, indtil den når den sidste enhed i kæden. Som det sidste certifikat anses for at have tillid til, at gå tilbage til det i sidste ende udgør autentifikation af en st certifikat.

Tilbagekaldelsesliste

Et certifikat kan blive ugyldigt af mange årsager, såsom naturlig udløb (overskridelse af gyldighedsdatoen), tab eller kompromis med den private nøgle, der er knyttet til certifikatet, ændring af mindst et felt inkluderet i certifikatindehaverens / indehaverens navn og ekstreme tilfælde tab eller kompromis med den private nøgle hos certificeringsmyndigheden, der underskrev det pågældende certifikat.

Dette er grunden til, at standarden definerer formatet på en liste, der angiver de certifikater, der er ugyldige for en given certificeringsmyndighed. Denne liste er underskrevet af certificeringsmyndigheden for at forhindre enhver ændring af en uautoriseret person.

Det inkluderer en udstedelsesdato, en opdateringsdato (begge valgfri) og selve listen i form af par (serienummer på det tilbagekaldte certifikat; mulig årsag til tilbagekaldelse) . Mønsteret kan kun være til stede i CRL'er i version 2-format.

En undertiden irriterende begrænsning af CRL'er er forsinkelsen med at udbrede tilbagekaldelsesoplysninger. For at reducere dette er OCSP- godkendelsesprotokollen udviklet. Defineret oprindeligt i RFC  2560 og derefter igen i RFC  6960, denne protokol giver nogenlunde de samme oplysninger som CRL'er, men potentielt mere opdaterede.

sikkerhed

Efter offentliggørelsen af en fuld kollision søgning angreb mod MD5 i 2004, Arjen Lenstra , Wang Xiaoyun, og Benne de Weger blev interesseret i X.509 bruge MD5 for certifikat-godkendelse. Deres angreb resulterede i smedning af to certifikater med identiske underskrifter. Brug af SHA-1 kryptografisk hash- funktion løser kun delvist problemet, da et lignende angreb er teoretisk muligt, selvom kompleksiteten ved at finde kollisioner på SHA-1 er meget større end på MD5.

Noter og referencer

  1. (in) "Anbefaling ITU-T X.509" , på ITU's websted, 2012 (adgang til 30. april 2016)
  2. [PDF] “The Directory - Authentication Framework” , på ITU-webstedet, 2008 (adgang til 30. april 2016)
  3. (in) "  Internet X.509 Public Key Infrastructure Certificate and CRL Profile  " Anmodning om kommentarer nr .  2459Januar 1999.
  4. (in) "  Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile  " Anmodning om kommentarer nr .  5280,Maj 2008.
  5. (in) "  Internet X.509 Public Key Infrastructur Online Certificate Status Protocol - OCSP  " Anmodning om kommentarer nr .  2560Juni 1999.
  6. (in) "  Internet X.509 Public Key Infrastructur Online Certificate Status Protocol - OCSP  " Anmodning om kommentarer nr .  6960Juni 2013.
  7. (i) Arjen Lenstra , Wang Xiaoyun og Benne de Weger , "Colliding X.509-certifikater" , på det sted, hvor Tekniske Universitet Eindhoven , 1 st marts 2005 (adgang 21 juli 2005)

Se også

Relaterede artikler

eksterne links

Løsninger:

Certificeringsmyndigheder:

Værktøjer (gratis):