Certifikat- & privat nøglematcher

Indsæt det certifikat, en server bruger, og den private nøgle, der skal udrulles sammen med det, og denne side svarer på det spørgsmål, en udrullet side fejler på: kommer de to fra samme nøglepar? Svaret er ikke et gæt ud fra modulus-længder eller fingeraftryk alene — siden signerer en fast udfordring med den private nøgle og verificerer signaturen med den offentlige nøgle inde i certifikatet. Hvis verifikationen går igennem, hører de to sammen; hvis den fejler, hjælper det ikke at redigere konfigurationen. Begge aflæsninger vises side om side med algoritme, nøglestørrelse, emneidentifikator og fingeraftryk af offentlig nøgle, og intet, der indsættes, forlader browseren.
1. Certifikat eller kæde
Indsæt så mange blokke, som ønskes. Hvert certifikat kontrolleres mod hver nøgle, så et certifikat plus én nøgle fortæller præcis, hvilket certifikat i kæden nøglen hører til — en almindelig overraskelse på en server, der serverer det forkerte certifikat fra en pakke. PEM, en ren base64- eller hexadecimal krop og en PKCS#7 .p7b-fil læses alle; certifikatkontrollen reviderer selve certifikatet, når nøglen er afklaret.
2. Privat nøgle eller den offentlige nøgle
PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 (BEGIN RSA PRIVATE KEY), SEC1 (BEGIN EC PRIVATE KEY) og en ren SPKI-offentlig nøgle (BEGIN PUBLIC KEY) forstås alle, ligesom en nøglefil indsat som base64 eller hexadecimal. En krypteret PKCS#8-nøgle (BEGIN ENCRYPTED PRIVATE KEY) kan ikke læses af en browser og rapporteres som sådan, med kommandoen der fjerner adgangskoden.
ikke kontrolleret endnu
Eksemplet er et selvsigneret certifikat og den private nøgle, der hører til det, begge lavet til denne side og uden at beskytte noget. Erstat nøglen med en hvilken som helst anden nøgle for at se den anden dom, eller slip den offentlige nøgleblok i stedet for den private for at se, at den offentlige nøgle matcher.
En privat nøgle, der indsættes på en hvilken som helst webside, bør overvejes først. Denne side er én fil med almindelig JavaScript, den indlæser intet udefra og laver ingen forespørgsel, så nøglen læses, bruges og glemmes inde i denne fane. Det er stadig et løfte fra kode, man kan læse, snarere end en garanti fra et netværk, man kan se: ved håndtering af en produktionsnøgle bør der arbejdes offline, og den sikreste kontrol er den samme openssl-kommando på egen server. En nøgle indsat her gemmes aldrig, lægges aldrig i en fil og sendes aldrig nogen steder — heller ikke af eksportknapperne, som skriver fund om nøglen og aldrig nøglen selv.
Hvorfor signering er svaret. To filer kan ligne hinanden og alligevel være en uoverensstemmelse: RSA-nøgler sammenlignes efter modulus i de fleste guides, men det virker kun for RSA, og en nøgle kan have det rigtige modulus med en beskadiget eksponent eller forkert padding. Denne side beviser parret, som et handshake gør — signér en fast udfordring med den private nøgle, verificér den med den offentlige nøgle i certifikatet — så dommen gælder for RSA, ECDSA og Ed25519 ens. Når kun den offentlige halvdel er indsat, sammenlignes de offentlige nøglebytes selv med dem i certifikatet, hvilket er lige så afgørende for identitet, men uden bevis for at nogen har den private halvdel.

Hvad et match ikke fortæller. At nøglen er den, serveren faktisk har indlæst, at certifikatet er betroet, at nøglefilen er intakt på disken, eller at nøglen ikke er kopieret af andre. Det kan heller ikke sige, om certifikatet er det, en klient vil modtage, da en load balancer eller et CDN foran siden kan servere et andet. For at kontrollere, hvad en live-server faktisk præsenterer, køres openssl s_client -connect example.com:443 -servername example.com -showcerts, og outputtet indsættes i certifikatfeltet.

Hvor filerne kommer fra. Certifikatet er det, serveren er konfigureret med, eller det, der er eksporteret fra en browser eller taget ud af en .p7b-pakke. Den private nøgle er den fil, webserveren læser ved opstart, typisk noget i stil med privkey.pem eller server.key. Hvis nøglen er krypteret, dekrypteres en kopi først med openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-plain.pem, og den kopi indsættes, hvorefter kopien slettes.
Matchrapport
Ikke kontrolleret endnu. Indsæt et certifikat og en nøgle ovenfor, og tryk på Kontrollér, om de matcher. Dommen vises her med beviset bag, og rapporten kan kopieres eller gemmes.
Den samme kontrol med openssl, på egen maskine
# offentlig nøgle inde i certifikatet openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256 # offentlig nøgle inde i den private nøgle openssl pkey -in key.pem -pubout | openssl pkey -pubin -outform DER | openssl sha256 # de to digests er kun ens, når parret hører sammen # den ældre RSA-only metode: sammenlign moduli openssl x509 -in cert.pem -noout -modulus | openssl md5 openssl rsa -in key.pem -noout -modulus | openssl md5
Sammenligningen af digests virker for alle nøgletyper og svarer til det fingeraftryk af offentlig nøgle, som siden rapporterer, mens modulus-sammenligningen kun findes for RSA. Ingen af dem beviser, at nogen har den private halvdel — det gør signeringstesten ovenfor, og det er derfor, siden bruger den.
Hvad rapporten indeholder. Dommen, parret af aflæsninger den kom fra (algoritme, nøglestørrelse, kurve, emneidentifikator og fingeraftryk af offentlig nøgle for certifikatet og for nøglen) og den nøjagtige test, der blev kørt. Rapporten indeholder aldrig selve den private nøgle: nøglen bruges til at lave en signatur og skrives ikke ind i teksten, JSON eller udklipsholderen. Det, man kopierer eller gemmer, er sikkert at vedhæfte til en ticket; den nøgle, der blev indsat, er det ikke, og udklipsholderen skal betragtes som det eneste andet sted, den nogensinde har eksisteret.

Privatliv: certifikatet og nøglen læses inde i fanen, intet uploades, og siden laver slet ingen forespørgsel — der er ingen probe og ingen opslag på denne side. For at oprette et matchende par bruges generatoren for selvsignerede certifikater; til at bede om et certifikat til en nøgle, der allerede findes, bruges CSR-generatoren; til at læse, hvad et certifikat indeholder, bruges certifikatdekoderen.