8

I've noticed a subtle difference in how OpenSSL and certreq generated PKCS10 CSRs:

  • OpenSSL:

      -----BEGIN CERTIFICATE REQUEST-----
    
  • Microsoft certreq:

      -----BEGIN NEW CERTIFICATE REQUEST-----
    

(and a footer with the same, except for END)

The PKCS10 spec doesn't have any information on these headers / footers, so I suspect they're not part of the spec. I would like to be able to handle as many formats of CSRs as possible, so:

Is there a spec for CSRs 'BEGIN' headers?

Also: do other forms of CSR header exist? What do CSR generation tools that aren't openssl or certreq use?

Community
  • 1
  • 1
mikemaccana
  • 110,530
  • 99
  • 389
  • 494
  • Possible duplicate of http://stackoverflow.com/questions/5355046/where-is-the-pem-file-format-specified – zakjan Feb 21 '15 at 03:47
  • 1
    @zakjan it's a different question, since the PEM spec RFC1421 doesn't include the actual headers http://www.rfc-editor.org/internet-drafts/draft-josefsson-pkix-textual-10.txt. The draft spec jariq mentioned below however does: http://www.rfc-editor.org/internet-drafts/draft-josefsson-pkix-textual-10.txt However the person asking the other question (where is the PEM format defined) is actually interested in the answer to this question (is there a spec for CSR begin headers). So it's not a duplicate, but they are closely related. – mikemaccana Feb 24 '15 at 11:23

2 Answers2

8

Is there a spec for CSRs 'BEGIN' headers?

Yes, but it depends on what standard you are following.

As @jariq pointed out, RFC 7468 is one of them.

But its also a lot like xkcd: Standards.


I've noticed a subtle difference in how OpenSSL...

The PEM encodings OpenSSL recognizes can be found in <openssl dir>/crypto/pem/pem.h>. Using NEW is apparently an old way of doing it.

Here is the list:

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
# define PEM_STRING_X509         "CERTIFICATE"
# define PEM_STRING_X509_PAIR    "CERTIFICATE PAIR"
# define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
# define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
# define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
# define PEM_STRING_X509_CRL     "X509 CRL"
# define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
# define PEM_STRING_PUBLIC       "PUBLIC KEY"
# define PEM_STRING_RSA          "RSA PRIVATE KEY"
# define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
# define PEM_STRING_DSA          "DSA PRIVATE KEY"
# define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
# define PEM_STRING_PKCS7        "PKCS7"
# define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
# define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
# define PEM_STRING_PKCS8INF     "PRIVATE KEY"
# define PEM_STRING_DHPARAMS     "DH PARAMETERS"
# define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
# define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
# define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
# define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
# define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
# define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
# define PEM_STRING_PARAMETERS   "PARAMETERS"
# define PEM_STRING_CMS          "CMS"

And a quick grep reveals:

$ grep -R -B 3 PEM_STRING_X509_OLD *
...
--
crypto/pem/pem_lib.c-
crypto/pem/pem_lib.c-    /* Permit older strings */
crypto/pem/pem_lib.c-
crypto/pem/pem_lib.c:    if (!strcmp(nm, PEM_STRING_X509_OLD) && !strcmp(name, PEM_STRING_X509))
--
...

I would like to be able to handle as many formats of CSRs as possible

It looks like "NEW CERTIFICATE REQUEST" (old style) and "CERTIFICATE REQUEST" (new style) are the two winners.


Someone once asked for a list of the PEM headers and footers (they are called pre- and post- encapsulation methods or strings, IIRC). The IETF's PKIX Working Group declined it. See PEM file format rfc draft request.

jww
  • 97,681
  • 90
  • 411
  • 885
5

Take a look at RFC7468 for CSR headers and footers.

Community
  • 1
  • 1
jariq
  • 11,681
  • 3
  • 33
  • 52
  • 1
    Since you posted this originally, and it was removed by an over-eager moderator, I petitioned to get it restored and this seems to have been successful. I've removed my own answer since you deserve both the points and the credit here. – mikemaccana Apr 22 '15 at 12:46
  • 1
    How does the above link answer the question? Are there any useful excerpts? – mwfearnley Aug 10 '17 at 16:27
  • 1
    [Section 7](https://tools.ietf.org/html/rfc7468#section-7), I believe. RFC documents don't really change so it's usually safe to link them, I guess. – cprn Oct 04 '18 at 10:55