I have some question about the X.509 v3 extensions. What extensions should appear in a proper certificate for a SSL server ?
Asked
Active
Viewed 1.1k times
2 Answers
12
No extension is strictly necessary in the SSL server certificate, but some extensions can only help:
- An
Authority Key Identifierextension will help clients link the certificate with the issuing CA. - A
CRL Distribution Pointsextension (non critical) should be used to point to the URL where the CRL should be found. - An
Authority Information Accessextension can be used to include a pointer (URL) to the certificate for the issuing CA itself; the same extension can point to an OCSP responder, if applicable. - If a
Key Usageextension is used, it should include some flags:keyAgreementandkeyEnciphermentfor RSA keys to use with TLS_RSA_* cipher suites,digitalSignaturefor RSA and DSA keys to use with the TLS_DHE_* cipher suites (there is some confusion about whetherkeyAgreementorkeyEnciphermentshould be used in the case of RSA-based key exchange, so it is safest to include both flags). - If you have a formally defined certificate policy, have a pointer to it (OID + download URL) included in all certificates in the path, or at least the SSL server certificate itself: it will give you some legal protection, should disputes arise.
- The
Subject Alt Nameextension should be used to indicate the SSL server name. In the absence of such an extension, all browsers will fallback to the CN component of the subjectDN, but this extension is still nominally "preferred" (see RFC 2818 for details).
Of course, all these extensions are supposed to be enforced by the issuing CA, so if you already have the CA, there should be no extra question here.
If in doubt, consult the Internet X.509 PKI Profile. The profile defines what you should morally follow. If you fully conform to it, your certificates will work everywhere. Browsers are actually much more lenient than that.
Thomas Pornin
- 326,555
- 60
- 792
- 962
-2
Hope the below link could help you, http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html
Yiddish
- 1
-
2Hi, and welcome to our site. Answers are much more helpful if they have information in them and links to back them up with further detail if necessary. By just providing a link, nobody can determine the merits of your answer and another site may change the URL of a given page. – Jeff Ferland Jan 09 '13 at 07:34
cAflag is defined asDEFAULT FALSE, which means "omit the flag if it is false". Therefore, if you include theBasic Constraintsextension in a non-CA certificate, then its _encoding_should be that of an emptySEQUENCE. – Thomas Pornin Jan 27 '13 at 13:53SEQUENCE { cA BOOLEAN DEFAULT FALSE; }wherecAhas valueFALSEshould be30 00, not30 03 01 01 00(in hexadecimal). That's what I meant. I was hypothesizing that your teacher was grumpy about how you encoded the extension, not about the presence of that extension. From RFC 5280, it is clear that putting the Basic Constraints extension in a non-CA certificate is allowed, and not even discouraged (it is a MAY, not a SHOULD or SHOULD NOT). However, the encoding of that extension must be valid. I don't know what irked your teacher; I am just exploring possibilities. – Thomas Pornin Jan 28 '13 at 19:45