CSR Generator

People speak of generating a certificate, and the phrase hides who does what. You do not make your certificate. You make a key pair and a short application, and somebody else decides whether to turn that application into a certificate.

The application is the certificate signing request. Its format has barely moved in a generation: the syntax in use today was republished in November 2000 from an older industry series, and its authors were candid about one design goal. They wanted requests to be small, because some certificate authorities of the day accepted them on paper.

What the form contains

A request has 3 parts. First comes the certification request information: a version number, the name you want in the certificate, your public key, and a set of attributes. Then comes the name of a signature algorithm. Last comes a signature over the first part, made with the private key that matches the public key inside.

That is all. The version is always 0, since no other version has ever been defined. There is no issuer in a request, no serial number and no dates. The specification leaves those to the authority, which builds the certificate from your name and key together with its own choice of serial number, validity period and signature algorithm.

The attributes are the flexible part. Two matter in practice. One is a challenge password, defined as a password by which the requester may later ask for revocation, with its meaning left to the issuer. The other is an extension request, which carries a list of certificate extensions you would like the authority to include. Subject alternative names travel this way, and so do key usage and extended key usage when you ask for them.

For transport the bytes are usually wrapped as text: Base64 in lines of 64 characters between a begin line and an end line labeled CERTIFICATE REQUEST. An older label with the word NEW in front is still in wide use, and readers are allowed to treat the two as the same thing.

Why the key stays where it was made

The signature is the clever part, and it is easy to misread. It does not prove who you are. It proves that whoever assembled the request holds the private key for the public key inside it. The specification gives the reason plainly: without that proof, someone could ask for a certificate naming themselves over another party’s public key.

So the request is a proof of possession, and a proof of possession is exactly what lets the private key stay home. The authority needs the public key, which is in the request, and evidence that you control the other half, which is the signature. It never needs the private key itself. A request can be pasted into a web form, mailed, or printed, and nothing secret has moved.

The rules for public authorities lean the same way. For a web server certificate, an authority must not generate the key pair on the subscriber’s behalf, and nobody but the subscriber may archive the subscriber’s private key without authorization. If an authority learns that a private key has reached an unauthorized party, it must revoke every certificate that contains the matching public key.

This is why the sensible place to make a request is the machine where the key will be used. A browser can do it too. The web cryptography interface makes a key pair inside the browser and marks each key as extractable or not, and a page that makes the key extractable can hand it to you as a file. That file then needs the care any private key needs. A page that keeps nothing loses the key when it closes, and then the certificate issued for it is useless.

What the authority reads, and what it ignores

A request asks. It does not instruct. The syntax document says the authority may use the attributes, along with other information it knows, to construct certificate extensions. May is the operative word.

Public authorities are bound to verify what they certify. They must confirm control of every domain name and IP address that goes into a certificate, and any other subject detail must be something the authority verified independently of the applicant. The plainest case is a domain validated certificate. Its subject may hold a verified country and a common name copied from the alternative names, and must not hold any other attribute. The organization and locality you typed into the request were never checked, so they cannot be certified, and they are left out.

Automated issuance makes the division explicit. In the ACME protocol the client first orders a certificate for a list of identifiers and proves control of each one, then finishes by sending a request. The request must name exactly the same identifiers as the order, in the common name, in a requested subject alternative name extension, or in both. The server may refuse a request that asks for extensions it is unwilling to include. Even the encoding is stripped down: the request travels as the Base64 of its raw bytes, without the begin and end lines.

The authority also looks at the request itself. The same protocol lists two questions an authority should weigh: is the key strong enough, and is the request signed with an acceptable algorithm? A request is checked before it is trusted, like any other form.

Names: the part most often wrong

For years a server’s name went into the common name field of the subject. That field is free text, and nothing in it says whether it holds a host, a person or a department. The current rules for checking a server’s identity are blunt about it: the common name must not be used to identify a service. Clients read the subject alternative names instead.

A request for a server certificate should therefore list every name in the alternative names. Public TLS certificates must carry that extension. A common name is now discouraged, and if one is present it must be a character for character copy of one of the alternative names. The classic mistake is a request with a host in the common name and no alternative names at all. It leaves the authority to supply the one field that clients actually read.

Alternative names are typed, which is their whole advantage. Each entry is tagged as a DNS name, an IP address, an email address or a URI. An IP address is stored as four or sixteen raw octets, not as text. A wildcard is allowed only as the complete left-most label.

Names outside ASCII need one more step, because the field that holds a DNS name is limited to ASCII. Each such label is stored in a converted form: a fixed four-character prefix followed by the Punycode encoding of the label. The German word for books, with its u-umlaut, becomes xn--bcher-kva. A converted label, like any DNS label, may not exceed 63 octets.

Choosing a key, and the usual mistakes

There are three families to choose from, and for a public web certificate only two. Public authorities must refuse an RSA key under 2048 bits, and may accept elliptic curve keys only on the curves P-256, P-384 and P-521. Their rules add that no other algorithms or key sizes are permitted, which for now leaves Ed25519 to private authorities.

Size is not strength. NIST rates a 2048-bit RSA key at 112 bits of security strength and a 3072-bit one at 128, the same level as a key on the 256-bit curve. The curve key is far smaller. That is why, in the tool above, a request with a P-256 key comes to under 300 octets while one with a 4096-bit RSA key runs past a thousand. NIST no longer allows RSA keys below 2048 bits, or the SHA-1 hash, for making signatures.

Then there is reuse. Nothing in the format stops you from sending the same key in request after request, and a renewal with an unchanged key is convenient. NIST’s guidance on key lifetimes explains what it costs: a limited lifetime limits the amount of exposure if a single key is compromised. A new key with each certificate means an old leak stops mattering when the old certificate expires.

Build the request for www.example.org in the tool above and look at the decoded tree. The request information starts at offset 4 and runs 185 octets. At offset 7 sit the three octets 02 01 00: an integer, one octet long, with the value 0, the version. The common name follows at offset 21 as 0c 0f and the fifteen letters of the host. The attributes begin at offset 129 with the tag a0, and inside them each alternative name appears with the tag 82: first 82 0f and the same fifteen letters, then 82 0b and the eleven letters of example.org. Only the signature at the end changes from one build to the next.

Other slips are simpler. A challenge password is not encrypted; anyone who sees the request can read it. And a private key pasted into a support ticket in place of the request is no longer private. The two files look alike, which is reason enough to read the label on the first line.

A decoder can confirm that a request is well formed, that its signature matches its key, and that its choices are ones an authority will accept. It cannot tell whether the key has been used before, whether the machine that made it was sound, or whether you control the names. Those questions belong to you and to the authority, and the request is only where the conversation starts.