Style Guides are very time sensitive. As the (2000) indicates this was written almost twenty years ago and as such some of this advice is not very pertinent in 2018 although doubtless joy can still be gleaned from laughing at the quotes.
A good number of X.509 profiles are mentioned, some of which still exist. This being Hacker News you probably only actually care about PKIX (the profile used for the Internet)
And so as a result there's a bunch of advice here you definitely shouldn't follow, instead:
Almost all the advice about serial numbers should be ignored. If you are expected to choose serial numbers, use a large (e.g. 160-bit) random number, the only relevant property is uniqueness and you won't be issuing enough certificates for 160-bit random numbers to be non-unique in a practical sense. If you find that making 160-bit random numbers is too hard, stop here and fix that because you are going to keep needing random numbers, this is cryptography.
Subject Alternative Names must actually be handled as distinct names, all of which are subjects of this certificate. Peter's idea of a "true" alternative name may have made sense in Peter's head for some purpose but it's not what SANs were conceived for and isn't how they're being used. Implementations that handle name constraints need to understand how to constrain SAN dnsNames and/or SAN rfc822 names as appropriate to the application. This is, contrary to Peter, actually easier for Alternative Names because unlike DNs their meaning is not only well defined but actually the real world usage corresponds to this defined meaning well too.
I found this document extremely helpful while writing cl-tls. Gutmann also points out a phenomenon he calls "bug conformance", where a major implementation of a spec (Microsoft's, in this case) has a bug, and thus nearly everyone else has to introduce this bug to conform. A curiously common phenomenon in the industry.
A good number of X.509 profiles are mentioned, some of which still exist. This being Hacker News you probably only actually care about PKIX (the profile used for the Internet)
And so as a result there's a bunch of advice here you definitely shouldn't follow, instead:
Almost all the advice about serial numbers should be ignored. If you are expected to choose serial numbers, use a large (e.g. 160-bit) random number, the only relevant property is uniqueness and you won't be issuing enough certificates for 160-bit random numbers to be non-unique in a practical sense. If you find that making 160-bit random numbers is too hard, stop here and fix that because you are going to keep needing random numbers, this is cryptography.
Subject Alternative Names must actually be handled as distinct names, all of which are subjects of this certificate. Peter's idea of a "true" alternative name may have made sense in Peter's head for some purpose but it's not what SANs were conceived for and isn't how they're being used. Implementations that handle name constraints need to understand how to constrain SAN dnsNames and/or SAN rfc822 names as appropriate to the application. This is, contrary to Peter, actually easier for Alternative Names because unlike DNs their meaning is not only well defined but actually the real world usage corresponds to this defined meaning well too.