CSR-decoder

Voordat een certificeringsinstantie (CA) een TLS-certificaat ondertekent, levert u haar een certificaatondertekeningsverzoek (CSR) aan: een blok Base64 met het onderwerp dat u op het certificaat wilt en uw publieke sleutel, plus een handtekening die bewijst dat u de bijbehorende privésleutel bezit. Deze decoder leest een PEM-gecodeerde CSR en toont de velden van het subject en de parameters van de publieke sleutel, zodat u de algemene naam, de organisatie en de sleutelgrootte kunt controleren voordat u het verzoek aan een CA overhandigt.

Zo decodeert u een CSR

  1. 1

    Plak de CSR

    Neem de markeringen `-----BEGIN CERTIFICATE REQUEST-----` en `-----END CERTIFICATE REQUEST-----` op. Witruimte wordt getolereerd.

  2. 2

    Voer de decoder uit

    Het verzoek wordt ontleed en de velden van het subject en de publieke sleutel worden uitgelezen.

  3. 3

    Controleer de uitvoer

    Controleer de velden van het subject zoals de algemene naam en de organisatie, plus het algoritme en de grootte van de sleutel.

  4. 4

    Handel naar het resultaat

    Als het subject of de sleutel er niet goed uitziet, genereer de CSR dan opnieuw voordat u deze aan een CA overhandigt.

Wat de decoder toont

Een CSR is een ASN.1-structuur (PKCS #10). De decoder leest er twee dingen uit:

  • Subject: de gevraagde Distinguished Name-velden, doorgaans land (C), organisatie (O), organisatie-eenheid (OU), plaats (L), provincie (ST) en algemene naam (CN).
  • Publieke sleutel: het algoritme (RSA, EC, DSA) en de sleutelgrootte in bits.

De handtekening in de CSR is wat de CA bewijst dat de aanvrager de bijbehorende privésleutel bezit. Deze decoder toont haar niet; de CA verifieert haar wanneer het verzoek wordt verwerkt.

Voorbeeld van uitvoer

Bij een typisch domeingeverifieerd verzoek ziet de uitvoer er zo uit:

Subject: commonName=www.example.com, organizationName=Example Inc., countryName=US
Key bits: 2048
Key type: RSA

De exacte attribuutnamen in het subject hangen af van hoe het verzoek is gegenereerd.

Velden om dubbel te controleren

  • Algemene naam (CN): moet de primaire hostnaam zijn. Moderne browsers negeren de CN en kijken alleen naar de SAN’s, maar veel CA’s vereisen nog steeds een geldige CN.
  • Alternatieve namen van het onderwerp (SAN’s): vermeld elke hostnaam en wildcard die het certificaat zal beveiligen. Browsers vergelijken met de SAN’s, niet met de CN.
  • Land (C): een tweeletterige ISO-code (US, GB, DE); geen volledige naam. CA’s wijzen foutieve codes af.
  • Sleutelgrootte: RSA 2048 is het minimum; 3072 of 4096 voor hogere beveiliging. ECDSA P-256 is een goed modern alternatief en levert een kleiner certificaat op.
  • Handtekeningalgoritme: SHA-256 of beter. SHA-1 is al lang verouderd en wordt afgewezen.

Over de alternatieve namen van het subject (SAN’s)

De decoder toont het subject van het verzoek, maar niet de SAN-extensie. Browsers matchen certificaten tegen de SAN’s en niet tegen de CN. Als het certificaat extra hostnamen moet dekken, neem ze dan op bij het genereren van het verzoek, bijvoorbeeld:

openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Wanneer de decoder de CSR niet kan ontleden

De meest voorkomende oorzaken zijn een afgekapt of beschadigd PEM-blok:

  • Afgekapte tekst: plak het volledige blok opnieuw, inclusief beide markeringen.
  • Toegevoegde regeleinden: plak het blok precies zoals het is gegenereerd.
  • Verkeerde inhoud: een publieke sleutel, certificaat of privésleutel die per ongeluk is geplakt, wordt niet als CSR ontleed.

Genereren van de passende sleutel

Een CSR wordt altijd gecreëerd samen met een privé sleutel. Typische opdracht:

openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr

Of voor ECDSA:

openssl req -new -newkey ec:<(openssl ecparam -name prime256v1) -nodes -keyout example.key -out example.csr

Bescherm de privé sleutel; als deze lekken, moet het certificaat worden ingetrokken.

Veelgestelde vragen

Een CSR bevat uitsluitend openbare informatie (publieke sleutel, onderwerp en SAN’s) plus een handtekening; deze kan veilig worden gedeeld met een CA of in een decoder worden geplakt. Wat geheim moet blijven, is de bijbehorende privésleutel.

Nee. Deze decoder verwacht de tekstvorm PEM met de markeringen BEGIN/END CERTIFICATE REQUEST. Voor een binair DER-verzoek converteert u het eerst naar PEM, bijvoorbeeld met openssl req -in request.der -inform DER -out request.pem.

Nee. De meeste publieke CA’s (Let’s Encrypt, DigiCert, Sectigo) vereisen alleen de CN en de SAN’s; zij negeren O, OU, L, ST en C bij domeingevalideerde certificaten. Certificaten met organisatievalidatie en uitgebreide validatie controleren die velden afzonderlijk.

Meestal omdat de geplakte tekst is afgekapt of er regeleinden in zijn geslopen, of omdat er een sleutel of certificaat is geplakt in plaats van een CSR. Plak het volledige blok opnieuw tussen de twee markeringen.

Gerelateerde tools

Tool beschikbaar in andere talen