Matchning av certifikat och privat nyckel

Klistra in certifikatet som en server använder och den privata nyckel som ska distribueras med det, så besvarar den här sidan frågan som en utplacerad webbplats misslyckas på: kommer de två från samma nyckelpar? Svaret är inte en gissning utifrån modulslängder eller fingeravtryck ensamma — sidan signerar en fast utmaning med den privata nyckeln och verifierar signaturen med den publika nyckeln i certifikatet. Om verifieringen går igenom hör de två ihop; om den misslyckas hjälper det inte att redigera konfigurationen. Båda avläsningarna visas sida vid sida med algoritm, nyckelstorlek, identifierare för subjektnyckel och fingeravtryck för publik nyckel, och ingenting som klistras in lämnar webbläsaren.
1. Certifikat eller kedja
Klistra in så många block som behövs. Varje certifikat kontrolleras mot varje nyckel, så en kedja plus en nyckel visar exakt vilket certifikat i kedjan den nyckeln hör till — en vanlig överraskning på en server som serverar fel certifikat från ett paket. PEM, ren base64- eller hexadecimal kropp och en PKCS#7-fil .p7b läses alla; certifikatkontrollen granskar själva certifikatet när nyckeln är klarlagd.
2. Privat nyckel, eller den publika nyckeln
PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 (BEGIN RSA PRIVATE KEY), SEC1 (BEGIN EC PRIVATE KEY) och en ren SPKI-offentlig nyckel (BEGIN PUBLIC KEY) förstås, liksom en nyckelfil klistrad som base64 eller hexadecimal. En krypterad PKCS#8-nyckel (BEGIN ENCRYPTED PRIVATE KEY) kan inte läsas av en webbläsare och rapporteras som sådan, tillsammans med kommandot som tar bort lösenfrasen.
ingenting kontrollerat ännu
Exemplet är ett självsignerat certifikat och den privata nyckel som hör till det, båda gjorda för den här sidan och skyddar ingenting. Byt nyckeln mot någon annan nyckel för att se det andra utfallet, eller släpp in offentlighetsblocket i stället för den privata nyckeln för att se att den publika nyckeln matchar.
En privat nyckel som klistras in på en webbsida bör man tänka två gånger på först. Den här sidan är en enda fil med vanlig JavaScript, den laddar inget från någonstans och gör ingen förfrågan, så nyckeln läses, används och glöms inne i den här fliken. Det är fortfarande ett löfte gjort av kod som man kan läsa snarare än en garanti från ett nätverk man kan se: om det gäller en produktionsnyckel, arbeta offline och betrakta den säkraste kontrollen som samma openssl-kommando på den egna servern. En nyckel som klistras in här lagras aldrig, läggs aldrig i en fil och skickas aldrig någonstans — inte heller av exportknapparna, som skriver ut fynd om nyckeln men aldrig själva nyckeln.
Varför signering är svaret. Två filer kan se lika ut och ändå vara en felmatchning: RSA-nycklar jämförs med modulus i de flesta guider, men det fungerar bara för RSA, och en nyckel kan ha rätt modulus med en skadad exponent eller fel utfyllnad. Den här sidan bevisar paret på samma sätt som en handskakning gör — signera en fast utmaning med den privata nyckeln, verifiera med den publika nyckeln i certifikatet — så att utfallet gäller för RSA, ECDSA och Ed25519 lika. När bara den publika halvan klistras in jämförs de publika nyckelbyten med dem i certifikatet, vilket är lika avgörande för identitet, men utan bevis för att någon innehar den privata halvan.

Vad en matchning inte avgör. Att nyckeln är den som servern faktiskt läst in, att certifikatet är betrott, att nyckelfilen är intakt på disken eller att nyckeln inte kopierats av någon annan. Det kan inte heller säga om certifikatet är det en klient kommer att få, eftersom en lastbalanserare eller ett CDN framför webbplatsen kan servera ett annat. För att kontrollera vad en live-server faktiskt presenterar, kör openssl s_client -connect example.com:443 -servername example.com -showcerts och klistra in utdata i certifikatrutan.

Var filerna kommer ifrån. Certifikatet är det som servern är konfigurerad med, eller det som exporterats från en webbläsare eller plockats ut ur ett .p7b-paket. Den privata nyckeln är filen som webbservern läser vid start, typiskt något i stil med privkey.pem eller server.key. Om nyckeln är krypterad, avkryptera en kopia först med openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-plain.pem, klistra in den och ta sedan bort kopian.
Matchningsrapport
Inget kontrollerat ännu. Klistra in ett certifikat och en nyckel ovan och tryck på Kontrollera om de matchar. Utfallet visas här med underlaget bakom, och rapporten kan kopieras eller sparas.
Samma kontroll med openssl, på den egna datorn
# offentlig nyckel i certifikatet openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256 # offentlig nyckel i den privata nyckeln openssl pkey -in key.pem -pubout | openssl pkey -pubin -outform DER | openssl sha256 # de två digesterna är lika endast när paret hör ihop # det äldre sättet som bara gäller RSA: jämför moduler openssl x509 -in cert.pem -noout -modulus | openssl md5 openssl rsa -in key.pem -noout -modulus | openssl md5
Jämförelsen av digest fungerar för alla nyckeltyper och stämmer med den publika nyckelns fingeravtryck som sidan rapporterar, medan jämförelsen av modulus bara finns för RSA. Ingen av dem bevisar att någon innehar den privata halvan — det gör signeringskontrollen ovan, och det är därför sidan använder den.
Vad rapporten innehåller. Resultatet, de två avläsningar det utgick från (algoritm, nyckelstorlek, kurva, identifierare för subjektnyckel och fingeravtryck för publik nyckel för certifikatet och för nyckeln) och det exakta test som kördes. Rapporten innehåller aldrig själva den privata nyckeln: nyckeln används för att skapa en signatur och skrivs inte in i texten, JSON:en eller urklippet. Det som kopieras eller sparas är säkert att bifoga i ett ärende; nyckeln som klistrades in är det inte, och urklippet ska räknas som den enda andra platsen där den någonsin funnits.

Integritet: certifikatet och nyckeln läses i fliken, ingenting laddas upp, och sidan gör inga förfrågningar alls — det finns ingen sondering och ingen uppslagning på den här sidan. För att skapa ett matchande par, använd generatorn för självsignerade certifikat; för att begära ett certifikat för en nyckel som redan finns, använd CSR-generatorn; för att läsa vad ett certifikat innehåller, använd certifikatavkodaren.