mail this page
products | company | support | training | contact us
This is a survival guide to the eye-glazing topic of TLS/SSL and X.509 (SSL) certificates - including self-signed certificates. These are elements in what is loosely called a Public Key Infrastructure (PKI).
What are colloquially known as SSL certificates should be referred to as X.509 certificates. The term SSL certificate became common due to the adoption of the X.509 (one of the ITU X.500 Directory standards) certificate format by Netscape when it designed the original versions of the SSL protocol, eons ago, when the world was still young and the Internet was a friendly place. The term 'SSL certificate' has persisted simply because given the choice of saying SSL certificate or 'X.509 certificate' which would you choose?
The current guide includes SSL, TLS, some detail about X.509 and its usage as well as some explanation about certificate types, including EV certificates, and the trust process. Creating self-signed certificates is presented as a worked example of the use of the OpenSSL package.
You can either buy an SSL (X.509) certificate or generate your own (a self-signed certificate) for testing or, depending on the application, even in a production environment. Good news: If you self-sign your certificates you may save a ton of money. Bad news: If you self-sign your certificates nobody but you and your close family (perhaps) may trust them. But before you shell out all that filthy lucre for a bright, shiny new X.509 (SSL) certificate or the even more expensive EV SSL (X.509) certificate you might want to know what they do and how they do it. And if your eyes glaze over when people start talking about SSL, security and certificates - start glazing now. This stuff ain't fun.
<ingrained habits> The RFC hyperlinks in the page below link to a plain text version which was copied to our site when the RFC was issued. We started doing this a long time ago when the world was young, RFCs were maintained in some strange places, occasionally moved location, and performance and reliability of the repositories was very variable (being generous). None of these conditions apply today, far from it. The IETF, like IANA, have solid web sites with excellent performance and continually improving features. Nevertheless, we persist in our ingrained habit for no particularly good reason (old dog...new tricks..).
If you want/prefer/need more choice of RFC format then the following information will dazzle and beguile you. The main repository for RFCs is maintained by the IETF, text versions may be viewed at www.ietf.org/rfc/rfcXXXX.txt (where XXXX is the 4 digit RFC number - left padded with zeros as necessary). The RFC may also be viewed in text format at http://datatracker.ietf.org/doc/rfcXXXX/ (where XXXX is the 4 digit RFC number - left padded with zeros as necessary) which also contains various RFC status information together with a list of alternative formats, such as, PDF and HTML. Finally, there is a searchable RFC list.
If, however, you just want to read the blasted RFC, feel free to click the links below.</ingrained habits>
We update the page from time-to-time and now keep a change log.
The major use of SSL (X.509) certificates is in conjunction with the TLS/SSL protocol. Secure Sockets Layer (SSL) is a Netscape protocol originally created in 1992 to exchange information securely between a web server and a browser where the underlying network was insecure. It went through various iterations and is now at version 3 (dating from 1995) and used in a variety of client<->server applications. Since the demise of Netscape the SSL specifications will not be updated further. The IETF standardized Transport Layer Security (TLS) Version 1, a minor variation of SSL, in RFC 2246, Version 1.1 in RFC 4346 and Version 1.2 in RFC 5246. In addition, a number of extensions are defined in RFC 3546 when TLS is used in bandwidth constrained systems such as wireless networks, RFC6066 defines a number of TLS extensions carried in an extended client hello format (introduced with TLS1.2), RFC6961 defines a method for reducing traffic when a client requests the server to supply certificate status information.
When a secure connection is initially established it will, depending on the implementation, negotiate support of the particular protocol from the set SSLv3, TLSv1, TLSv1.1 or TLSv1.2. Such is the pervasive power of the name SSL that in most cases what is called SSL is most likely using TLS - for instance OpenSSL supports both SSL (v3) and TLS (TLSv1, TLSv1.1 and TLSv1.2) protocols. While there are detail differences between SSL and TLS the following descriptions apply to both protocols. Note: SSLv2 was banned by RFC 6176 which contains a dire list of its shortcomings.
TLS/SSL runs on top of TCP but below the end user protocol that it secures such as HTTP or IMAP as shown in Figure 1.
Figure 1 - TLS/SSL Layering.
TLS/SSL does not have a well-known port number - instead when used with a higher layer protocol, such as HTTP, that protocol designates a secure variant, HTTPS in the case of HTTP, which does have a well-known (or default) port number. The designation HTTPS simply indicates that normal HTTP is being run on top of an TLS/SSL connection, which runs over TCP. In the case of HTTPS the well-known port number is 443, in the case of IMAPS - port 993, POP3S - port 995 etc..
The next level of description requires some familiarity with the terms MAC (Message Authentication Code), Secure hashes, symmetric and asymmetric cryptographic algorithms. For those not comfortable with these terms they are covered in in this Encryption survival guide. You may want to lie down for a while in a darkened room after reading this stuff.
A related protocol, Datagram Transport Layer Security (DTLS), defines a secure service when used with UDP (RFC 6347). While the priciples are similar to TLS this guide does not discuss DTLS further.
The term TLS 1.2 Suite B (defined by RFC 6460) defines a cipher suite (see below) compatible with NSA Suite B Cryptography and is only relevant when TLS is used for US national security applications.
When a secure connection is established using TLS/SSL, for example using HTTPS (default port 443), an exchange of messages occur between the client - which always initiates the connection - and a server. The first set of messages are called the Handshake Protocol after which both client and server enter the Record (or Data) Protocol. The exchange of messages during the Handshake Protocol achieves the following objectives:
Establishes the protocol variant to be used from the supported set (depending on the implementation) of SSLv3, TLSv1, TLSv1.1, TLSv1.2 - the latest possible variant will always be used, thus TLSv1 would always be used in preference to SSLv3 assuming both client and server support both. The client offers a list - the server makes the choice from the offered list.
Sends authentication data. The server sends authentication information most normally in the form of (wrapped in) an X.509 (SSL) certificate but other methods are supported by the protocol.
Establishes a session ID so that the session can be restarted if required.
Negotiates a Cipher Suite consisting of a key-exchange algorithm together with a bulk-data encryption algorithm type and a MAC type used in the subsequent data session (Record Protocol). The key-exchange algorithm typically uses an asymmetric (public-private key) algorithm such as RSA, DSA or ECC (Elliptic Curve Cipher - see RFC5289). Asymmetric algorithms are very expensive in resources (CPU) and therefore symmetric ciphers are used for subsequent bulk-data encryption (using the Record Protocol). The key-exchange algorithm is used to transfer information from which session key(s) can be independently computed for the symmetric (bulk-data) cipher. The MAC protects the integrity of the transmitted/received data during the Record Protocol.
This a simplified overview and additional data may be exchanged, for instance, the client can be requested to send an authenticating X.509 (SSL) certificate in a process called mutual authentication, but the above describes the most common case and is illustrated in Figure 2 below:
Figure 2 - TLS/SSL Protocol Sequences
The Handshake Protocol negotiates and establishes the connection and the Record Protocol transfers (encapsulates) the encrypted data stream such as HTTP, SMTP or IMAP.
In Figure 2 messages in black are sent in clear, messages in blue are sent using the public key supplied by the server (using the key-exchange cipher), messages in green are sent using the negotiated bulk-data cipher and are protected by the negotiated MAC.
TLS/SSL allows for a data compression algorithm to be negotiated as part of the cipher suite. Given the speed of modern networks data compression is rarely, if ever, used and is typically set to the value NULL (not used).
This section provides more detail about the TLS/SSL protocol message exchanges (Figure 2 above) for those who revel in the grisly details. If you prefer the 'stuff happens' level skip this section to retain your sanity.
ClientHello (1): The ClientHello offers a list of protocol versions/variants supported, the supported cipher suites in preferred order and a list of compression algorithms (typically NULL). The client also sends a 32 octet random value (a nonce), which is used later to compute the symmetric keys, and a session ID which will be 0 if no previous session exists or non-zero if the client thinks a previous session exists.
Each cipher suite is comprised of a key-exchange algorithm, a bulk cipher algorithm and a MAC (Hash) algorithm.
The cipher suite used by both client and server on initial connection is:
TLS_NULL_WITH_NULL_NULL (0x00, 0x00) # the first NULL is the key exchange algorithm # the following WITH_NULL defines the bulk cipher # the final NULL defines the MAC
This value indicates no encryption will occur and thus all messages are sent in clear until the Client Key Exchange (ClientKeyMessage).
A typical cipher suite is:
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00, 0x0A) # RSA is the key exchange algorithm # the WITH_3DES_EDE_CBC defines the bulk cipher # (Triple DES with Cyclic Block Chaining) # SHA is the MAC (Hash)
Valid cipher suite values may be found in Appendix C of the relevant TLS RFC (RFC 2246 for TLS 1, RFC 4346 for TLS 1.1 and RFC 5246 for TLS 1.2). These are updated for ECC (Elliptic Curve Ciphers) by RFC 4492 and RFC 7027.
The word EXPORT appears in some valid cipher suite descriptions and refers to export strength ciphers, that is, some ciphers are only permitted in certain countries (see US Dept. of Commerce, Bureau of Industry and Security(BIS) and the Wassenaar Arrangement) and should be borne in mind when configuring systems that may be used internationally.
Extensions, defined in RFC 3546 and primarily used in wireless networks, may be invoked in a backward compatible manner at ClientHello. RFC6066 significantly increases the number of TLS extensions including many which may be used on conventional (non-wireless) networks. The server is free to silently ignore any extensions it does not understand.
RFC6066 introduced a TLS Certificate Status extension type which essentially says 'I (the client) absolutely do not trust your (the server) certificate but I will absolutely trust your (the server) response to my (Certificate Status) request for certificate validity(!)'. The response to the Certificate Status request (obtained typically by using OCSP is sent in a CertificateStatus message immediately after the Certificate message (see below). Apparently, Certificate Status has proved wildly popular (for wireless devices?) and is in danger of destroying OCSP servers. RFC6961 introduces a 'certificate_request_v2' extension which reduces the traffic volumes from the TLS server to the OCSP server by allowing it to store OCSP responses and from the TLS server to the TLS client by allowing it to send all pertinent information including that for intermediate certificates within a single CertificateStatus message.
RFC 6066 defines an optional extension (Server Name Indication - SNI) that allows the client to send the server name, such as www.example.com, when making the initial TLS/SSL connection. This feature (supported by most modern browsers) allows a web server supporting multiple web sites, for example, Apache's VirtualHost capability, to send a site specific certificate in its Certificate (3) message. (Configuration of Apache 2 to support SNI.)
RFC 7250 defines the extension client_certificate_format which can be used to indicate the format of certificate being used and may be either the normal X.509 format or a RawPublicKey format in which the certificate is reduced to only the subjectPublicKeyInfo attribute in the subsequent certificate transfer messages(s) of the Handshake protocol.
ServerHello (2): The ServerHello returns the selected protocol variant/version number, cipher suite and compression algorithm. The server sends a 32 octet random value (a nonce) which is used later to compute the symmetric keys. If the session ID in the ClientHello was 0 the server will create and return a session ID. If the ClientHello offered a previous session ID known to the server then a reduced Handshake is negotiated. If the client offered a session ID that was not recognized by the server, the server returns a new session ID and a full Handshake results.
RFC 7250 defines the extension server_certificate_format which can be used to indicate the format of certificate being used and may be either the normal X.509 format or a RawPublicKey format in which the certificate is reduced to only the subjectPublicKeyInfo attribute in the subsequent certificate transfer messages(s) of the Handshake protocol.
Certificate (3): The server sends its X.509 certificate which contains the public key of the server and whose algorithm must be the same as the key exchange algorithm of the selected cipher suite suite. There are other methods offered by the protocol to transfer the public key - it could for example simply point to a DNS KEY RR - but an X.509 certificate is the normal method and universally supported. The objective of this message is that the client will obtain from a trusted source the public key of the server which it can use to send an encrypted message.
While it is normal to only send a single certificate in this message what is called a certificate bundle (more than one certificate in a single file PEM file) can be sent. For example, certificate bundles can be defined using the Apache directive SSLCertificateChainFile whereas a single certificate would be defined using the SSLCertificateFile directive. Bundles are typically used when cross-certificates are present during some form of certificate re-structuring, for example, a corporate takeover of one CA company by another or a change of key/keysize from the CA.
The DNSSEC DANE protocol (RFC6698) allows a client to obtain a copy of the server X.509 certificate from the DNS. However, a certificate obtained from the DNS using DANE is in addition to that obtained in the normal certificate exchange of TLS/SSL and allows extra verification for the perennially paranoid while doing little, if anything, to increase security.
RFC 7250 defines a vestigal certificate format that encapsulates the raw public key in a wrapper consisting of the SubjectPublicKeyInfo (necessary to describe the public key properties). This is a modest move toward a saner solution of obtaining the public key directly from an authenticated source such as a DNSSEC secured DNS RR.
ServerDone (4): Indicates the end of the server part of this dialogue sequence and invites the Client to continue the protocol sequence. Note: The server may request a client certificate at this point to complete mutual authentication. This client certificate exchange sequence has been omitted from the protocol sequence description since it is not commonly used and unnecessarily complicates the description.
Note: If, during the initial TLS/SSL negotiation, the server requested a client certificate then the client must send this (in the same format as defined for the server with the exception that RFC 6066 allows any client to send a certificate URL rather than a full certificate) immediately following the ServerDone and prior to the ClientKeyExchange.
ClientKeyExchange (5): The client computes what is called a pre-master key using the server and client random numbers (or nonces). It encrypts this key using the public key of the server obtained from the supplied X.509 certificate. Only the server can decrypt this message using its private key. Both sides independently compute a master key from the pre-master key using an algorithm defined in the standard. Any required session key is derived from this master key.
ChangeCipherSpec - Client (6): This message indicates that all subsequent traffic from the client will be encrypted using the selected (negotiated) bulk encryption protocol and will contain the negotiated MAC. Nominally this message is always encrypted with the current cipher which, in the connection's initial state, is NULL and hence the message is shown in the diagram as being sent in clear. While this message is shown in the protocol diagram as a being sent separately it is frequently concatenated with the Client Key Exchange message.
Finished - Client (7): This message contains all the messages sent and received during the Handshake protocol, but excluding the Finished message, and is encrypted using the negotiated bulk encryption protocol and hashed using the negotiated MAC. If the server can decrypt and verify this message (containing all previous messages), using its independently computed session key, the dialog was successful. If not the session is terminated at this point by the server sending an Alert message with some (perhaps vague) error message.
ChangeCipherSpec - Server (8): This message indicates that all subsequent traffic from the server will be encrypted using the negotiated bulk encryption protocol and contain the negotiated MAC. Nominally this message is encrypted with the current cipher, which in the connection's initial state is NULL and hence the message is shown in the diagram as being sent in clear. Implicity receipt of this message also tells the client that the server received and was able to process the client's Finished message.
Finished - Server (9): This message contains all the messages sent and received during the Handshake protocol, but excluding the Finished message, and is encrypted using the negotiated bulk encryption protocol and includes the negotiated MAC. If the client can decrypt this message using its independently computed key the dialog was successful. If not he client would terminate the connection with and Alert message and a suitable (perhaps vague) error code.
Record Protocol: Subsequent messages between the server and client are encrypted using the negotiated bulk encryption protocol and include the negotiated MAC.
The random values sent by the client and server and the subsequent pre-master secret all include a two octet time value (to avoid replay attacks) and consequentially, as in all cryptographic systems, both client and server should be using a synchronized time source such as NTP.
When either the client or the server terminates a connection with an Alert message the error code supplied may not be precise (and rarely helpful) to avoid providing information to the other party which could be used to refine an attack.
The original ITU-T standard, from which the certificate gets its infamous name, is X.509 - one of the X.500 directory speccification suite of standards. The use of X.509 certificates on the Internet is standardized by the IETF with RFC 5280 defining the X.509 certificate format and RFC 4210 which defines the Certificate Management Protocol (CMP) protocol used to access and process X.509 certificate requests (though a number of additional protocols - discussed below - are used to handle and validate certificates). Finally, RFC 3739 defines what it calls a Qualified Certificate which is related to the European Directive on Electronic Signature (Directive 1999/93/EC).
X.509 uses a whole new and wonderful world of terminology. Specifically it uses the term Distinguished Name (DN) to refer to fields within a certificate. DNs are defined by the IETF within the LDAP series of RFCs - particularly RFC 4514. The terms Abstract Syntax Notation 1 (ASN.1) and Object Identifiers (OIDs) are also used which are both described in ITU X.680 series and finally encoding uses Distinguished Encoding Rules (DER) described in ITU X.690.
There are also a significant number of standards relating to certificate handling marked PKCS#X (where X is a number), for instance PKCS#10 defines the format of a Certificate Signing Request (CSR). These refer to standards defined by RSA Laboratories. A number of these standards have been reproduced, essentially unchanged, as RFCs, for example, PKCS#10 referred to above has been published as RFC 2986 (updated by RFC 5967). In addition to the IETF, RSA and ITU-T, X.509 has been further standardized by a number of countries as well as industry organizations. Observers and implementors have noted that the multiplicity of standards can lead to serious problems in implementation and interpretation. This set of implementation notes from Peter Gutmann is pretty detailed, big and really quite scary.
An X.509 certificate provides two distinct capabilities:
An X.509 certificate (currently X.509v3) acts as a container for the public key that may be used to verify or validate an end entity (EE) such as a web site or an LDAP server. The entity is defined in the subject field of the certificate. The subject is described in the form of a Distinguished Name (DN) - backgrounder about DNs in LDAP - which is comprised of a number of Relative Distinguished Names (RDNs) each of which is a data-containing element called an Attribute. Specifically, the CN (commonName) attribute (RDN) of the Distinguished Name typically contains the end-entity covered by the certificate. An example of a CN may be a web site address such as CN=www.example.com. A full subject DN may contain one or more of the following RDNs CN= (commonName, the end-entity being covered, example, a website or www.example.com), C= (country), ST= (state or province within country), L= (location , nominally an address but ambiguously used except in EV certificates where it is rigorously defined), OU= (organizationalUnitName, a company division name or similar sub-structure), O= (organizationName, typically a company name).
The X.509 certificate is digitally signed by a trusted Authority (typically called a Certificate Authority or simply a CA) - identified by a Distinguished Name (DN) in the issuer field of the certificate - both to ensure that the certificate has not been tampered with and to attest (or certify) that the public key for this subject field really, really is the public key for this subject. This trust process is described further. The signing Authority may be a Certification Authority (CA), Registration Authority (RA) or some other intermediate authority (such as a subordinate CA) or it may be self-signed. Note: The private key associated with the public key of the user's X.509 certificate is always maintained by the user and is never divulged to the signing Authority.
A separate X.509 structure called a Certificate Revocation List (CRL - currently CRLv2) provides information about certificates that have been revoked or invalidated for a variety of reasons. CRLs are essentially an old-fashioned 'batch' process. They contain big(ish) lists of all the certificates that have been revoked. If the certificate being checked (using its serial number) is not in the CRL it is assumed to be still valid. CRLs have multiple problems: the CRL may only be updated periodically by the CA (certificate issuer), because the CRL is big browsers will only download it, if at all, reluctantly and sporadically. In short, its not a very useful or eficient process. Increasingly an on-line version called OCSP can be used to check the current status of a specific (again using the serial number) certificate.
Most of the information in this section focuses on the use of X.509 for validating server communication, X.509 may also be used for other purposes such as personal identification (including digital signatures) and S/MIME which we may get round to when (if) our heads stop hurting.
X.509 (SSL) certificates use a bewildering range of terminology - sometimes it is even consistently applied, mostly it is not, which further adds to the confusion. Even the RFCs do not rigorously define their terminology though RFC 4210 comes closest. CAs typically offer a number of certificate types. With the exception of EV certficates and Qualified certificates which have precise meanings and defintions, these certificate types are mostly marketing concepts - designed to offer differing price/functionality points - and therefore typically their descriptions offer only a nodding aquaintance - at best - with the technical terminology. Finally, not all CAs are equal. Readers are cautioned that while most CAs are thoroughly professional and undertake periodic audits or are certified by national organizations not all are (look for, and follow, attestation, certification and audit links on any CA website). Buyer beware (caveat emptor) is the watchword.
The following list attempts to define the most commonly used terms covering both certificate authorities and certificate types given the caveat of the previous paragraph. The explanations offered are culled from technical documents (mostly the source RFCs and especially RFC 4210) and CA web sites.
Certificate Authority (a.k.a. root CA): The term Certificate Authority is defined as being an entity which signs certificates in which the following are true: the issuer and subject fields are the same, the KeyUsage field has keyCertSign set and/or the basicConstraints field has the cA attribute set TRUE. Typically, in chained certificates the root CA certificate is the topmost in the chain but RFC 4210 defines a 'root CA' to be any issuer for which the end-entity, for example, the browser has a certificate which was obtained by a trusted out-of-band process. Since final authority for issuing any certificate rest with this CA the terms and conditions of any intermediate certificate may be modified by this entity.
Registration Authority (a.k.a. Registration CA): A Registration Authority (RA) may be required in certain environments to handle specific certificate characteristics, for example, an RA may be delegated by a National Certificate Authority (CA) to specialize in personal certificates, while another may specialize in Server certificates. An RA, if present, is essentially an administrative convenience. RAs can sign certificates (as subordinate CAs) but, having carried out appropriate end-entity validation, may also pass the request to a root CA for signature.
Subordinate Authority (a.k.a. Subordinate CA): Generic term. Any entity that signs a cerificate but is not a root CA. Some subordinate CAs - especially those that are entirely operated under the control of the root CA owner - may be marked as CAs (the extension BasicContraints will be present and cA will be set True). Thus, an RA, assuming it signs certificates, would do so as a subordinate CA and if operated under the control of a root CA may also be marked as a CA.
Intermediate Authority (a.k.a. Intermediate CA): Imprecise term occasionally used to define an entity which creates an intermediate certificate and could thus encompass an RA or a subordinate CA.
Cross certificates (a.k.a. Chain or Bridge certificate): A cross-certificate is one in which the subject and the issuer are not the same but in both cases they are CAs (BasicConstraints extension is present and has cA set True). They are typically used where a CA has changed some element of its issuing policy (a new key expiry date or new key) or where one CA has been taken over by another CA and certificates issued by the merged CA are chained back to the new owner to allow previously issued root certificates to be retired. The term Chain certificate, when applied in this context, indicates that a new chain has been created and can, occasionally, be referred to as a bridge certificate (it chains or bridges to a new CA). Cross certificates can be installed at the server (as part of a certificate bundle - see note under TLS protocol - Certificate) but when used for backward compatibility, for example, when an EV certificate is processed by a non-EV compliant client the cross certificate is installed at the client. Other than setting the cA field to True (which, frankly, makes little difference) the Cross certificate is a normal Intermediate certificate.
Intermediate certificates (a.k.a. Chain certificates): Imprecise term applied to any certificate which is not signed by a root CA. Intermediate certificates form a chain and there may be any number of intermediate certificates from the end-entity certificate to the root certificate. Intermediate certificates may be issued by subordinate CAs, RAs and even CAs directly (though technically these should be called cross-certificates) to assist in transitions, take-overs or even just to differentiate brands. The term chain in this context is meaningless (but sounds complicated and expensive) and simply indicates that the certificate forms part of a chain.
Certificate Bundle: Generic term which indicates that more than one X.509 certificate is concatenated into a single file (normally a PEM format file). Certificate bundles can be sent during a TLS/SSL handshake. Typically, certificate bundles are used for administrative purposes during some CA transition, for example, a take-over, a change of policy, key change, key expiry date change etc..
Qualified certificates: Defined in RFC 3739 the term Qualified certificates relates to personal certificates (rather than server certificates) and references the European Directive on Electronic Signature (1999/93/EC) which is focussed on uniformly defining an individual for the purposes of digital signature, authorization or authentication. Specifically, the RFC allows the subject field to contain in priority order commonName (CN=), givenName (GN=) or pseudonym= and the subjectDirectoryAttributes may be present and contain any of dateOfBirth=, placeOfBirth=, gender=, countryOfCitizenship= and countryOfResidence=. Finally, two new optional extensions biometricInfo and Qualified Certificate statements (qcStatements) are defined in the RFC. The Qualified certificate is recognized by the presence of a qcStatements extension with the value qcStatement-2. Most national governments have defined a number of additional fields for inclusion in these certificates. In some cases for genuine reasons in other cases simply to flex national muscles and make implementor lives thoroughly miserable.
non-Qualified certificates: Normally a personal certificate which does not conform to the standard defined for Qualified certificates. Can also be used as a term of abuse by the issuers of Qualified certificates to imply an inferior quality certificate.
Multi-host certificates: A server certificate typically contains a CN=hostname attribute, for example CN=www.example.com, in the subject. The hostname is resolved by the DNS and can yield multiple IP addresses (if there are multiple A or AAAA RRs in the DNS). In this case any X.509 (SSL) server certificate for the same hostname may be replicated onto all such hosts (clearly the users private key also needs to be replicated to each host which may present problems if hardware crypto devices are used - in this latter case some CAs will be delighted to sell you additional certificates called Multi-host certificates which get round the problem). Where multiple hostnames exist, such as www.example.com and example.com or www1.example.com then these require special treatment and special certificate types and are defined under multi-domain certificates and wildcard certificates below.
Multi-domain certificates: Some CAs sell multi-domain certificates for covering situations such as www.example.com and example.com or even www.example.net. This is achieved by using multiple entries in the subjectAltName field and is described further. Technically, there are few limits to this process, for example, www.example.com and www.example.net could be supported by a single X.509 (SSL) certificate but most CAs have some commercial restrictions - which can usually be overcome if you part with more filthy lucre. Wildcard certificates, described below, can sometimes be used for this purpose but are limited to a single domain name.
Wildcard certificates: A number of CAs sell wildcard certificates where the subject field contains CN=*.example.com (the * is the wild card). Such certificates will support any hostname in the domain, thus *.example.com will support www.example.com and mail.example.com but not example.com or (obviously) example.net(see multi-domain certificates above).
EV Certificates (a.k.a. Extended Certificates): Extended Validation (EV) certificates are distinguished by the presence of the CertificatePolicies extension containing a registered OID in the policyIdentifier field. EV certificates are described in detail.
DV certificates: What are sometimes called Domain Validation (DV) certificates are issued by some CAs. The term is not universally used but implies that only the ownership of the domain name by the certificate requestor has been verified by the CA. Thus the CN= value, for instance www.example.com, in either the subject or subjectAltName can be treated as valid but organizational information (C=, ST=, L=, OU= or O=) should not be treated as valid and should be either blank or contain appropriate text such as "not valid".
OV certificates: What are sometimes called Organizational Validation (OV) certificates are issued by some CAs. The term is not universally used but implies that ownership of the domain name of the certificate requestor and its organizational details have been verified by the CA. Thus the CN=, C=, ST=, L=, OU= or O= values in either the subject or subjectAltName can be treated as valid. While this looks, on its face, pretty thorough such certificates are not EV certificates which require further qualification.
Domain-Only Certificates: A generic term, generally of abuse, applied to certificates whose end user verification process varies, in the view of the user of the term, from cursory to non-existent.
X.509 Certificates may be chained, that is, they may be signed by one or more intermediate Authorities in a hierarchical manner - or a certificate may simply be signed directly by a CA. The concept of a Registration Authority (RA) as an intermediate signing authority is introduced in the RFCs mentioned above. A Registration Authority (RA), sometimes also referred to as a subordinate CA in the EV standards, appears to describe an organization from which the X.509 certificate is actually purchased, for example, a licensed agent, who signs the certificate with the CA (the final signing authority) providing the ultimate or root authority. Somewhat similar in structure to DNS Registry Operators and Registrars for those familiar with the DNS organization. RFC 4158 contains a useful but indigestible and brain numbing discussion about how certificate chains can be reliably constructed using subject and issuer pairs augmented by, among others, SubjectKeyIdentifier and AuthorityKeyIdentifier.
The topmost certificate of the signing hierarchy is known as a root certificate, or sometimes a CA certificate or even a root CA certificate. Root certificates are obtained by a trusted out-of-band process (in the case of browsers they are distributed with the browser software and updated periodically) and when used to validate a certificate chain are generically referred to as trust anchors. When a end-entity certificate (or certificate bundle) is obtained from a server during an TLS/SSL handshake it must be verified by the receiving software all the way to the root or CA certificate including, if appropriate, any intermediate certificates (again these are typically distributed with browser software). A root or CA certificate is recognized if the issuer and subject fields are the same, if the KeyUsage field has keyCertSign set and/or the BasicConstraints field has the cA attribute set TRUE. The process of building the certificate chain is described by RFC 4158 and chain validation by RFC 5280. The chaining process is shown in Figure 3 below:
Figure 3 - X.509 Chaining
The issuer of a certificate is identified using a Distinguished Name (DN) format which was originally designed to represent a location within a DAP or LDAP DIT (Data Information Tree). The DN should not be confused with a network address or URL/URI. The DN will typically have a format such as CN=Type of Certificate, OU=Certificate Division, O=Certificate Company name,C=Country (CN=, OU=, O=, C= format) but may use simply an OU=, O=, C= format or even a CN=, O=, C= format and to make matters yet more complicated it could use CN=, OU=, DC=, DC= format. It can vary - a lot. A DN consists of a number of comma separated RDNs (Relative Distinguished Names), thus CN= or C= are RDNs in a DN. An X.509 certificate does not contain a URI to obtain any chained certificates via a network interface - but it may contain (in other fields) a URI to obtain CRLs. Applications that use certificates - such as a browser or client email software - must have previously obtained the root certificate, and if the certificate is chained - all intermediate certificates, by some out of band or off-line process. Most common CA root certificates are distributed with browsers (and made available to their associated client email software). Browsers and email clients also have user interfaces to enable addition of new certificates or replacement of existing certificates. In the case of Firefox: Tools->Options->Advanced->Encryption->View Certificates, MSIE: Tools->Internet Options->Content Tab->Certificates button->Trusted Root Certification Authorities.
Note: The root certificates distributed with common browser (and email client) software are added according to criteria defined by the browser supplier and vary from "pay us lots of cash" through to full proof of a CA audit and other requirements.
When an application accesses an TLS/SSL based service the server certificate (or a certificate bundle) is obtained during the initial TLS/SSL Handshake dialog. The application, such as a browser, will extract the CN of the subject DN field (and/or the subjectAltName - see RFC 6125) to verify the entity (say a web server address, for instance, www.example.com). It then uses the issuer field DN of the server's X.509 certificate to find the appropriate root certificate from its local store (and generate an exception - normally involving a highly confusing, and potentially dangerous, user dialog - if one is not found). If a valid root certificate is found this authenticates the server supplied certificate. The net result, assuming all goes well, is that the public key contained in the X.509 certificate is safe (is trusted) and can be used to communicate with the defined entity (the Subject).
Servers typically only require their own certificate(s) and do not require root certificates - they simply send their certificates to the client and do not have to validate certificates. However TLS/SSL does allow mutual validation - both server and client send certificates. If client certificates are required in the application then the server is required to validate the client certificate and must be provisioned with all the required root and intermediate certificates by some out of band process - such as email or obtaining them from CA web sites.
Figure 4 - X.509 Usage
An X.509 certificate is a data structure. Various protocols allow the certificates to be manipulated via a communications network. These X.509 Certificate Operations, such as sending a signing request, returning a signed certificate etc. are defined in, among others, the Certificate Management Protocol (CMP) - RFC 4210 - as well as PKCS #10 (RFC 2986) and further described in this guide.
Overview: A number of protocols are defined to manipulate certificates and CRLs (Certificate Revocation Lists). The Certificate Management Protocol (CMP RFC 4210 updated by RFC 6712) provides protocol methods to manipulate certificates (the format of the certificate messages (Certificate Request Message Format - CRMF) is defined in RFC 4211). RFC 4210 defines a number of communication methods (such as HTTPS) which may be used to transport certificate requests across a network but does not explicity define a transport protocol for certificate handling (see CMC/CMS next).
CMC/CMS (Certificate Management over CMS) defined in RFC 5272, RFC 5273, RFC 5274 and updated by RFC 6402 allows the secure transport of certificate requests from the requestor to the CA (including any intermediate RA(s)) and back. The message format may be either PKCS #10 (RFC 2896) or CMRF (RFC 4211). This protocol should always be referred to as CMC but is occasionally referred to as CMS. Technically, CMS is Cryptographic Message Syntax and describes only the envelope format for the request and response (in PKCS #10 or CRMF format). The protocol defines a number of operations that may be performed on certificates, including updating the trust anchors (root certificates) maintained by the certificate requestor. This is a big and juicy (read complex) protocol.
Online Certificate Status Protocol (OCSP RFC 6960) is a protocol for the on-line verification of certificates. RFC 6066 extends TLS to allow a client to request OCSP certificate status during the Handshake Protocol phase (and RFC 6961 defines a simplified 'certificate_request_v2' which attempts to reduce OCSP server traffic volumes).
Server-Based Certificate Validation Protocol (SCVP RFC 5055) allows multiple client functions to be delegated to an untrusted server, specifically certificate path validation and certificate path discovery. In the case where the SCVP server is trusted addition functionality may be provided such as certificate status (also provided by OCSP) and obtain intermediate certificates (also provided by CMP).
RFC 4387 defines some limited manipulation of X.509 certificates, keys or CRLs over HTTP using a GET method (which was the method we used the last time we paid filthy lucre for an X.509 certificate). RFC 4386 defines use of the DNS SRV RR to discover Certificate repositories, and OCSP services.
To be supplied.
To be supplied. Largely superseded by OCSP variants.
To be supplied.
The Online Certificate Status Protocol (OCSP) is defined in RFC 6960 and a streamlined, high-throughput, message format is defined in RFC 5019 (The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments) which, in essence, sensibly reduces OCSP requests to a single certificate and removes most of the OPTIONAL fields in requests and responses as noted below. RFC 6960 (which obsoletes RFC 2560 and 6277) simply clarifies a few points in the original RFCs, makes the RFC more compatible with RFC 5019 and adds its own, entirely new, obfuscation to the specification. RFC 6961 defines a new 'certificate_request_v2' which allows servers to cache (save) responses and allows information about all relevant certificates (including intermediary ones) to be sent in a single message request.
OCSP is an on-line alternative to a Certificate Revokation List (CRL). The URI of the service is typically identified in the AuthorityInfoAccess (AIA) field of a certificate if the CA supports an OCSP service. A client will send an optionally signed request identifying the certificate to be verified and receive a signed reply from the OCSP server indicating the status as being good, revoked or unknown. The RFC allows for a number of different transport protocols (and specifically mentions LDAP, SMTP and HTTP as examples) to transmit the request and responses with the specific transport scheme identified in the URI of the AIA field of the certificate being validated. The RFC also defines the format of HTTP messages (using GET and POST) when used for OCSP. The request and response messages are outlined below:
# request format OCSPRequest TBSRequest version 0 = v1 requestorName OPTIONAL requestList (one or more) (single request in the case of RFC 5019) reqCert hashAlgorithm AlgorithmIdentifier issuerNameHash Hash of Issuer's DN issuerKeyHash Hash of Issuers public key serialNumber CertificateSerialNumber singleRequestExtensions OPTIONAL requestExtensions OPTIONAL optionalSignature OPTIONAL
Signature of the OCSP request is optional and if present the requestorName will indicate the signer. Clearly, for the receiver to verify the signature it must have the public key of the signer (or its delegated agent).
Providers of EV (Extended Validation) certificates must provide an OCSP service, for all other certificate types it is optional.
# response format OCSPResponse responseStatus successful 0 --Response has valid confirmations malformedRequest 1 --Illegal request format internalError 2 --Internal error in issuer tryLater 3 --Try again later --(4) is not used sigRequired 5 --Must sign the request unauthorized 6 --Request unauthorized responseBytes OPTIONAL responseType OID (184.108.40.206.220.127.116.11.1.1 =BasicOCSPResponse) BasicOCSPResponse response ResponseData version 0 - Version DEFAULT v1 responderID EITHER OF byName 1 - Name byKey 2 - Hash of Issuers Public Key producedAt GeneralizedTime responses certID hashAlgorithm AlgorithmIdentifier issuerNameHash -- Hash of Issuer's DN issuerKeyHash -- Hash of Issuers public key serialNumber CertificateSerialNumber certStatus CertStatus good 0 revoked 1 unknown 2 thisUpdate GeneralizedTime nextUpdate GeneralizedTime OPTIONAL singleExtensions OPTIONAL responseExtensions OPTIONAL signatureAlgorithm AlgorithmIdentifier, signature Hash of Response data certs OPTIONAL
A certStatus of good is defined in the RFC to mean 'not revoked' but additional information may be available in Extension fields.
The responseStatus of unauthorized indicates the responder has no authoritative information about this certificate.
The response is normally signed by the CA that issued the certificate identified in serialNumber but the protocol allows for a delegated authority to sign the response in which case the response must include a certificate (carrying the delegated signers public key) in certs and which must be signed by the issuer of the certificate defined in serialNumber.
RFC 5019 defines a streamlined message format - which is entirely compatible with the full OCSP format - by removing most of the OPTIONAL fields to assist message throughput. PROTOCOL: Supports OCSP over HTTP only using GET and POST methods. REQUESTS: Limits the request to a single certificate (requestList will be 1), dispenses with the OPTIONAL field singleRequestExtensions, and the OPTIONAL structures requestExtensions and optionalSignature (if the request is signed, responders are free to ignore the signature). RESPONSES: By insisting on a single certificate per request RFC 5019 has already reduced complexity (and size) in the response, in addition the OPTIONAL responseExtensions is removed (but singleResponseExtensions may be included). Again, if the response is signed by a delegated authority the response must include a certificate (carrying the delegated signers public key) in certs and which must be signed by the issuer of the certificate defined in serialNumber.
OCSP is designed as a real-time system (unlike the batch nature of classic CRLs) thus, clients can theoretically, verify the status of any certificate before acceptance and use. Particularly when handling an EV certificate any client implementation, for example, a browser is really obliged to perform an OCSP check to meaningfully implement EV security. This means, for example, that every access to an HTTPS service can (in the case of EV should) result in an additional check to the OCSP service of the CA. As more sites implement the well intentioned, but ultimately misguided, policy of using HTTPS for everything (rather than the more meaningful and secure DNSSEC) OCSP server performance is rapidly degraded and servers are brought to their knees in a kind of benignly intended DDoS onslaught. RFC 6066 extends TLS by allowing the client to request certificate status from the TLS server (OCSPStatusRequest) and may have further exacerbated the OCSP load problem by making the OCSP interrogation trivial to implement - encouraging every client to request it. RFC 6961 tries to fix the OCSP load problem by using a new TLS 'certificate_request_v2' which seems (it is not definitive on when a server should interrogate OCSP) to allow caching of OCSP responses (thus reducing OCSP loads at the expense of real-time validity checks) at the server and enables multiple certificate status messages (including all intermediate certificates) to be sent in a single frame.
This section describes, in gruesome - but incomplete - detail, the format and meaning of the major fields (technically called attributes) within an X.509 certificate. The format is defined in RFC 5280.
Much use is made in X.509 (and LDAP) of that gruesome pseudo-Hungarian notation (or lowerCamelCase if you prefer the term). In general, poor X.509 implementations are case sensitive, good ones are not. Further, all the LDAP matching rules related to DN handling are case insensitive meaning that attribute names are not case sensitive.
RFC 7250 defines a vestigal certificate format for cases where the public key has been obtained by other (out-of-band) trusted methods. This minimal certificate format uses only the subjectPublicKeyInfo attribute (and its two sub-fields). Use of this minimal certificate format is indicated during the ClientHello and ServerHello messages during the TLS/SSL handshake.
An X.509 certificate printed by Openssl looks like this (the major fields are described below):
Certificate: Data: Version: 3 (0x2) Serial Number: bb:7c:54:9b:75:7b:28:9d Signature Algorithm: sha1WithRSAEncryption Issuer: C=MY, ST=STATE, O=CA COMPANY NAME, L=CITY, OU=X.509, CN=CA ROOT Validity Not Before: Apr 15 22:21:10 2008 GMT Not After : Mar 10 22:21:10 2011 GMT Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ae:19:86:44:3c:dd:38:df:e2:41:5f:d8:86:19: 69:7e:85:d7:1d:ae:1e:eb:87:b0:5f:fc:f3:db:e3: aa:82:76:d6:42:05:f1:0e:5c:5a:a2:8d:f6:d3:00: 37:04:96:13:06:16:e6:d1:67:14:69:cd:85:df:a7: b3:ac:a2:6c:33:cd:d6:00:3d:24:99:fa:4b:81:07: 0c:b2:5a:fe:06:16:da:34:66:63:78:31:7d:11:5e: 63:de:9e:ee:76:8b:0c:12:af:fb:f2:28:0a:76:5b: 99:20:b8:f7:c0:9c:e8:89:c5:d0:1e:e5:07:c8:bd: 38:c8:52:97:cc:76:c9:c8:2b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: EE:D9:4A:74:03:AC:FB:2C:FD:43:C7:58:6E:2E:6A:88:BA:65:61:CC X509v3 Authority Key Identifier: keyid:54:0D:DE:E3:37:23:FF:2E:E8:03:0A:2C:52:FE:FC:C0:C8:13:72:80 Signature Algorithm: sha1WithRSAEncryption 52:3d:bc:bd:3f:50:92:67:a3:d3:6f:37:a9:3f:89:b5:16:5b: 9c:0d:32:25:32:91:c7:bf:f6:0d:f8:6d:1c:09:45:2f:3f:b9: 18:b7:1c:8d:7c:06:33:ef:ca:e0:92:a3:90:3f:7c:4e:16:87: 67:ae:7c:2c:1a:43:e5:3a:24:d9:c3:7d:cf:bf:eb:01:9d:c1: f0:bb:0f:15:de:d5:9e:42:9d:f8:7f:0d:5b:af:59:80:d1:aa: cc:db:31:1b:d4:7f:f3:f1:71:25:85:c9:8b:78:3e:13:ac:11: 51:35:49:8d:c3:9a:bb:9a:89:2c:ef:7f:90:f9:05:b3:65:98: b8:74
The X.509 certificate consists of the following fields (Attributes):
|Version||In general this should indicate version 3 (X.509v3). Since the numbering starts from zero this will have a value of 2. If omitted version 1 (value 0) is assumed.|
|Serial Number||Positive number up to a maximum of 20 octets. Defines a unique serial number for each certificate issued by a particular Certification Authority (thus is not, of itself, a unique number) and used, among other purposes, in Certificate Revocation Lists (CRLs).|
|Signature||Must be the same OID as that defined in SignatureAlgorithm below.|
|Issuer||The DN (Distinguished Name) of the Authority that signed and therefore issued the certificate. This may or may not be the Certification Authority (CA). The issuer may comprise a subset of domainComponent (DC=), countryName (C=), commonName (CN=), surname (SN=), givenName (GN=), pseudonym=, serialNumber=, title=, initials=, organizationName (O=), organizationalUnitName (OU=), stateOrProvinceName (ST=) and localityName (L=) attributes. Only CN=, C=, ST=, O=, OU= and serialNumber= must be supported the rest are optional (serialNumber= is rarely present - but mandated for EV certificates - and L= is frequently present though widely misunderstood but its use is clarified for EV certificates) RFC 5280 appears to allow either of the globally unique methods (X.500 format O=, C= or the IETF format DC=, DC=) but the X.500 format seems universally preferred. An example issuer DN would look something like:
# shown split across two lines for presentation reasons only C=MY,ST=some state,L=some city,O=Expensive Certs inc, OU=X.509 certs,CN=very expensive certs # various interpretations of the RDN fields exist # the following are presented as generally accepted # values. # C = ISO3166 two character country code # ST = state or province # L = Locality; generally - city # O = Organization - Company Name # OU = Organization Unit - typically certificate type or brand # CN = CommonName - typically product name/brand
|Validity||Provides two sub-fields (Attributes) notBefore and notAfter which define the time period for which the certificate is valid - or if one is of a cynical persuasion the NotAfter value defines the point at which the user has shell out more filthy lucre to the CA or issuer. Dates up to 2049 are encoded as UTCTime (format is YYMMDDHHMMSSZ - yes a 2 digit year) after 2050 as GeneralizedTime (format is YYYYMMDDHHMMSSZ - finally a 4 digit year). Where Z is a literal constant indicating Zulu Time (UCT aka Greenwich Mean Time) - its absence would imply local time.|
|Subject||A DN defining the entity associated with this certificate. If this is a root certificate then issuer and subject will be the same DN (and BasicConstraints CA TRUE will be set). In an end user/server certificate the subject DN identifies in some way the end entity. Typically the CN attribute (RDN) of the DN will identify some unique name of the end entity being certified or authenticated. The subject may comprise a subset of domainComponent (DC=), countryName (C=), commonName (CN=), surname (SN=), givenName (GN=), pseudonym, serialNumber, title, organizationName (O=), organizationalUnitName (OU=), stateOrProvinceName (ST=) and localityName (L=) atributes. An example subject DN that will authenticate access to a web site could look something like:
# shown split across two lines for presentation reasons only C=MY,ST=another state,L=another city,O=my company,OU=certs, CN=www.example.com # various interpretations of the RDN fields exist # the following are presented as generally accepted # values. In the case of personal certificates GN=, SN= or pseudonym= # can appear in the fields # C = ISO3166 two character country code # ST = state or province # L = Locality; generally means city # O = Organization - Company Name # OU = Organization Unit - division or unit # CN = CommonName - end entity name e.g. www.example.com
However some certs use the issuer's DN and replace the CN attribute (RDN) with the name of the entity being authenticated thus the above could, based on the issuer example above, become:
# shown split across line for presentation reasons only C=MY,ST=some state,L=some city,O=Expensive Certs inc, OU=X.509 certs,CN=www.example.com
In the above example CN=www.example.com will work when the web site access URL is http://www.example.com, if the web site access also uses http://example.com the certificate checking process will fail and in this case the subjectAltName can be used to extend the certificate scope to include example.com (or any other domain name that is covered by this certificate).
While the majority of certificates currently (2011) use the CN= RDN of the subject field to describe the entity, RFC 6125 now recommends that the subjectAltName be used (containing the end entity name) and that the subjectAltName field be used in preference to CN= in the subject for validating the entity name. It may be some time before all applications and certificate issuers follow these principles and therefore to handle all possibilities the entity should appear in both a CN= (in the subject field) and in a subjectAltName field.
The subject field can be empty in which case the entity being authenticated is defined in the subjectAltName.
The form CN=www.example.com/emailAddressfirstname.lastname@example.org is frequently seen and generally created by default by OpenSSL tools when generating a Certificate Signing Request (CSR) and defines a second attribute (emailAddress) and which may, or may not, be present. Most CAs request that the email address prompt is left blank during the creation of the CSR when using OpenSSL - perhaps because they can sell you a second SSL certificate to protect your email addresses. Or is that excessively cynical?
|SubjectPublicKeyInfo||Contains two sub-fields (attributes), algorithm (the OID of the public key algorithm from the list defined in RFC 3279) and subjectPublicKey (the entity's public key as a bit string). An example of a the algorithm attribute when using an RSA algorithm (rsaEncryption) OID is shown below:
1.2.840.113518.104.22.168Note The vestigal certificate format defined by RFC 7250 consists only of this attribute and its two sub-fields.
|IssuerUniqueIdentifier||Optional. Defines a unique value for the issuer. The RFC recommends that this field is NOT present.|
|SubjectUniqueIdentifier||Optional. Defines a unique value for the entity being authenticated. The RFC recommends that this fields is NOT present.|
|Extensions||Tons of extensions are defined in the various RFCs - the following are only the most, IOHO, significant. Extensions may be marked as CRITICAL. Note: CRITICAL has an interesting and nuanced interpretation. If the software handling the certificate sees the CRITICAL value (which it can always interpret) but does not understand the extension it MUST abandon processing and NOT accept the certificate.|
|SignatureAlgorithm||The algorithm used to sign the certificate identified by its OID and any associated parameters. The following illustrates the RSA with SHA1 digital signature OID (sha1WithRSAEncryption):
1.2.840.113522.214.171.124This value must be the same as that identified in the signature field of the certificate. The currently valid OIDs for use with X.509 certificates are defined in RFC 3279.
|SignatureValue||Bit string containing the digital signature.|
All fields with the exception of SignatureAlgorithm and SignatureValue are encoded using ASN.1 DER (Distinguished Encoding Rules) defined by ITU-T X.690. The signature covers all DER encoded fields thus, obviously, excluding itself.
Multiple standards bodies (countries, industry organizations or governmental agencies) define specific profiles that refine the meaning of certain fields or attributes or mandate specific fields. All very confusing.
Certificate Revocation Lists (CRLs) are a method by which certificates may be invalidated before their NotAfter date has expired. CRLs are normally issued by the CA that issued the certificate and can be obtained by a variety of methods, for instance, LDAP, HTTP or FTP. CRLs (specifically CRLv2 the current version) are defined in RFC 5280 and updated by RFC 6818.
Theoretically, when a certificate has been received from a server the receiving software should verify that the certificate obtained does not appear in a CRL (has not been revoked). To minimise delay in catching revoked certificates the CRL check should be done by fetching the latest CRL whenever a certificate is received from a server. Since a CRL contains a list of all revoked certificates from any given CA it can be of considerable size thus creating, perhaps, an unacceptable overhead to an TLS/SSL initial connection. Further, depending on the CA's policy, the CRL may be updated every hour or 12 hours or daily etc.. The bottom line being that fetching a CRL file(s), even if it is done for every received certificate, may still yield an out-of-date result.
In practice a per certificate CRL fetch is rarely, if ever, performed and many systems rely on CRL caches that are periodically updated. RFC 5280 uses the weasely term suitably-recent to describe the CRL update frequency. An on-line version of the revocation list, known as Online Certificate Status Protocol (OCSP) is defined in RFC 2560, streamlined by RFC 5019 and updated by RFC 6277. A CRL has the following format:
|Version||Optional. In general this should indicate version 2 (CRLv2). Since the numbering starts from zero this will have a value of 1. If omitted version 2 (value 1) is assumed.|
|Signature||Must be the same OID as that defined in SignatureAlgorithm below.|
|Issuer||A DN of the Authority that signed and therefore issued the CRL. This may or may not be the Certification Authority. See also notes on issuer DN|
|ThisUpdate||The time and date at which the CRL was created. Date format may be UTCTime UTCTime (format is YYMMDDHHMMSSZ) or GeneralizedTime (format is YYYYMMDDHHMMSSZ). Where Z is a literal constant indicating Zulu Time (Greenwich Mean Time) - its absence would imply local time.|
|NextUpdate||The time and date at which the next CRL will be created. Date format may be UTCTime UTCTime (format is YYMMDDHHMMSSZ) or GeneralizedTime (format is YYYYMMDDHHMMSSZ). Where Z is a literal constant indicating Zulu Time (Greenwich Mean Time) - its absence would imply local time.|
|RevokedCerticates||The CRL identifies the revoked certificate by its serial number. Serial numbers are not globally unique but are defined to unique within CA therefore any client must use the a combination of the issuer to obtain a unique match.
userCertificate CertificateSerialNumber revocationDate Time crlEntryExtensions Extensions OPTIONAL
|Extensions||Multiple CRL extensions are defined in RFC 3280 none of which are marked as being CRITICAL and many are only relevant if the CRL is indirect, that is the CRL was issued by a party (an issuer) which was not the issuer of the certificates being revoked.|
|SignatureAlgorithm||The algorithm used to sign the CRL identified by its OID and any associated parameters. The following illustrates the RSA with SHA1 digital signature OID (sha1WithRSAEncryption):
1.2.840.1135126.96.36.199This value must be the same as that identified in the signature field of the certificate. The currently valid OIDs for use with X.509 certificates are defined in RFC 3279.
|SignatureValue||Bit string containing the digital signature for the CRL.|
As described previously an X.509 certificate is trusted to contain the public key of the entity defined (normally specifically the CN of the subject or subjectAltName). Trust is created during the certificate creation process. The process of obtaining an X.509 certificate will vary in detail from CA to CA but generally consists of the following steps:
The first, or topmost, link in the chain of trust is the Certification Authority (CA). CAs are deemed to be trusted organizations either because they say so or because they have passed some standard. In North America WebTrust is the most widely recognized CA standards organization and most CAs carry their seal indicating they have undergone an audit by a WebTrust accredited auditor (increasingly the major International auditing firms are also performing such audits). The very existence of the CA marks the first step in the establishment of the line of trust. The CA has, at some point in time, generated one or more asymmetric keys and, using the private key, has self-signed a certificate (the issuer and subject attributes of the X.509 certificate are the same and BasicConstraints cA is TRUE). This certificate is the root or CA certificate and the private key, whose public key is contained in the root certificate, is used to sign user certificates. Root (or CA) certificates are distributed to end user clients by a trusted out-of-band process, most frequently with browser installations.
A user who desires a certificate will review the products from the various Certificate Authorities (CAs) and select a preferred CA. An application is made to the selected CA - or one of its agents or Registration Authorities (RA) - for a particular type of SSL (X.509) certificate. Depending on the certificate type various information is required and (usually) verified such as name of business, business registration number or other identifying information. Again depending on the type of certificate further proof of identity may be required. This is essentially a clerical process (which may be automated to a greater or lesser extent) that establishes the next trust link.
The CA, which is trusted, is trusted to have established that the user is who they say they are. More or less.
Having selected the SSL product, supplied the required identification information and had it verified by the CA the user is then requested to generate a set of asymmetric keys and use the private key to sign a Certificate Signing Request (CSR) which will contain the public key of the generated public-private pair among other information. The CSR format is defined by RFC 2986 (a re-publication of the RSA standard PKCS#10) - updated by 5967 which consists of the following data:
|Subject||A DN defining the entity to be associated with this certificate. In general, depending on the CA policies, this will be the subject that will appear in the returned X.509 certificate.|
|SubjectPublicKeyInfo||Contains two sub-fields (attributes), algorithm (the OID of the public key algorithm from the list defined in RFC 3279) and subjectPublicKey (the entity's public key as a bit string). An example of a RSA algorithm (rsaEncryption) OID is shown below:
|Attributes||Optional. Attributes may contain a number of sub-fields (attributes) of which the following are noted, challengePassword (a password to further secure the CSR - most CAs insist this attribute is NOT present) and unstructuredName (any suitable text - again normally not required by CAs or ignored if present).|
|SignatureAlgorithm||The algorithm used to sign the CSR identified by its OID and any associated parameters. The following illustrates the RSA with SHA1 digital signature OID (sha1WithRSAEncryption):
1.2.840.1135188.8.131.52Note: The CSR is signed using the private key of the private-public key pair whose public key appears in the SubjectPublicKeyInfo of this CSR.
|SignatureValue||Bit string containing the digital signature.|
A CSR is created using this procedure.
The CSR is uploaded to the CA (typically using FTP or HTTP) which uses the data in the CSR and perhaps other information obtained during the SSL certificate application to create the user's X.509 certificate which typically has a validity period ranging from 1 to 3 years. The CA finally signs the user's certificate (the SignatureAlgorithm and SignatureValue) using the private key of the public-private key pair whose public key is contained in the CA's root certificate. The X.509 certificate is sent to the user using a variety of processes (FTP/HTTP/EMAIL).
The trust loop is therefore completed by the CA's digital signature. The digital signature of the user's certificate can only be verified by using the public key of the issuer which is contained in the CA's root certificate obtained by a (trusted) off-line process (normally via a browser installation).
When a certificate is received by a browser from a web site (during the Handshake Protocol of TLS/SSL) it must be verified all the way to the root or CA certificate (there may be one or more levels of certificates depending on the certifcate vendor). The root/CA (and any required intermediate) certificates are typically distributed with major browser software. Root/CA certificates distributed in this way are generically called trust anchors - a widely used term used to describe any base structure or information obtained by a trusted distribution route that may be used to validate/authenticate received information. RFC 5914 (with some support from RFC 5937) defines how such trust anchors may be organized, used and processed in the specific case of X.509/SSL certificates.
Extended Validation (EV) Certificates are defined by the CA/Browser Forum and include a mixture of improved clerical validation as well as technical processes. The objective behind EV certificates is to provide increased confidence to end users though the standard explicitly states that it does not guarantee the business practices of the certificate owner - merely that the owner does exist.
When using a supporting browser the user sees a normal padlock icon but the status bar shows up in GREEN when an EV certificate is encountered. Currently EV supporting browsers are: MSIE 7 only and the latest versions of Konqueror, Firefox (v3+) and Opera(9.5+). In general EV certificates are significantly more expensive than other types of certificates. The EV issuing standard has the following characteristics:
The CA has to be audited for EV compliance and undergo a yearly audit renewal.
Enhanced user verification - notably it demands that the CA verify that the applicant does indeed own the domain name that it is seeking to authenticate!
CAs follow the practices defined in RFC 3647 which has INFORMATIONAL status for the rest of us.
Standardizes the use and meaning of certain fields in the subject DN and adds some new ones. Specifically it defines the following to be REQUIRED (the EV standard's version of the RFC MUST)
Mandates that EV certificates may only be issued for server authentication at this time, that is, CN= must be a server name such as www.example.com or mail.example.com.
EV certificates are recognised definitively by the use of a registered OID (unique for each CA) in the CertificatePolicies field.
This section illustrates the use of OpenSSL commands to perform tasks associated with X.509 certificates. To illustrate the certificate process in its entirety it covers generation of what are loosely called self-signed certificates. Self-signing is one of those terms that needs a little explanation since it has two potential meanings.
At a strict level it means that the issuer and subject fields in the certificate are the same. In this sense every root certificate is a self-signed certificate. In the second sense it means that the user becomes their own Certification Authority (CA) and is an alternative to purchasing an X.509 certificate from a recognized CA such as Verisign or Thawte (and others) which are already trusted (their root/CA certificates are pre-installed on the user's computer) by most tools, for example, browsers. A user (end-entity) certificate obtained by a browser from a web site during the TLS/SSL Handshake Protocol phase and issued by one of the recognized CAs can be tracked back (and therefore authenticated) by the browser to the signing authority (the CA) by use of the issuer field in the certificate. The browser must have the trusted CA's root certificate installed (as well as any intermediate certificates) to avoid any browser error messages. The term trust anchor is used to defined such installed certificates. Trusted CA root certificates for most of the commercial CAs and many National CAs are distributed and installed with browsers such as MSIE, Firefox, Opera etc.
The rest of this section deals with the second definition of self-signing - the user becomes their own CA. This form of self-signing can be used either during testing or operationally where, for instance, a user wishes to control access within a private network, a closed user group or some other community of interest. Here the trust relationship, normally associated with an external CA, may be regarded as being implicit due to the nature of the organization signing the certificates.
The first time a self-signed certificate is presented to a user's TLS/SSL enabled software, such as a browser, and assuming the browser does not have a copy of the relevant root certificate, it will generate a message asking if the user wishes to accept the certificate. Alternatively, the self-signed root certificate can be pre-installed or imported to a user's computer in which case no browser error message will be generated.
Note about Certificate Validity Periods and Key Sizes: Many of the certificates in the following sections are valid for 1 to 3 years. However most of the commercial root certificates installed in browsers have validity periods of 10 to 20 years! Don't be afraid to use quite lengthy time periods to avoid the pain of renewing certificates. The current RSA key length recommendation (2011) is 2048 bits for lifetimes until 2030 (consequentially many of the current root certificates have expiry dates around 2028 giving them a couple of years to phase in extended bit sizes in time for the 2030 expiry of 2048 bits). RSA Key Strength Note and recommendations over required lifetime. The same keysize (2048 bits) and lifetime recommendation (until 2030) is also contained in US NIST (National Institute or Standards and Technology) Special Publication 800-57 Part 1 Rev2 Table 4.
The following sequences use OpenSSL commands (tested with OpenSSL 0.9.8n and 1.0.0e) to generate a self-signed X.509 certificate that may be installed and used by TLS/SSL server systems such as Web, FTP, LDAP or mail (SMTP Agent). OpenSSL commands use a bucket load of parameters - including reply defaults, certificate duration and certificate fields - from the openssl.cnf file (/etc/ssl/openssl.cnf - FreeBSD) and if you are going to do serious work with certificates it is well worth looking though this file and editing as appropriate to save some typing.
Note: There are dire text/comment warnings that editing either openssl.cnf or messing around with CA.pl (a useful scripy file) may cause the sun to fall out of the sky. Make a copy of both files before you do anything so you can always restore your system to a pristine state in the event anything goes wrong. The bottom line: mess with stuff at your own peril.
The files created when working with certificates will be a mixture of those containing public keys which are generally innocuous and those containing private keys which need to be rigorously protected. Whether both these types of files can be maintained in a single directory structure or not will be a matter of local security policy. The actual process depends significantly on the requirement. As with all sophisticated software there are usually about 6,000 ways of doing anything - we think there are just three Really Useful Methods (RUM)™.
FreeBSD Operational Note: When running tests on a new FreeBSD 8.1 install during which openssl is installed by default (0.9.8n) CA.pl was not installed. If you have requested installation of source then it may be found in /usr/src/crypto/openssl/apps/CA.pl. Alternatively, use the ports system (/usr/ports/security/openssl) and then make patch (just downloads and untars the latest version of openssl but does not install it) and then use find ./ -name "CA.pl". Since PERL is no longer installed by default with FreeBSD you may also need to install it.
Create a CA, a root certificate that can be imported into a browser for testing purposes and a single server certificate that can be used by a server such as Apache. The standard OpenSSL CA.pl script (which has been moved to /etc/ssl for convenience in the examples - choose an appropriate location) is used to simplify the process:
Note: If a certificate suitable for multiple server name use, for instance, example.com and www.example.com or www.example.net is required follow this procedure instead.
# by default the RSA algorithm is used with 1024 bit keys (2011) # to change defaults see Method 3: Bullet 1 # create directories and self-signed CA root certificate cd /etc/ssl ./CA.pl -newca # the DN sequence requested here will be for the CA # by default this creates a root certificate in # demoCA/cacert.pem # and the CA's private key in # demoCA/private/cakey.pem # cacert.pem is valid for 3 years ./CA.pl -newreq # creates a Certificate Signing Request (CSR) # the requested DN sequence will be for the # server name the only important value is # CN (CommonName) which should be the web or other server name # such as www.example.com, ldap.example.com or mail.example.com ./CA.pl -sign # signs the CSR # and leaves the certificate in # /usr/local/openssl/newcert.pem # newcert.pem is valid for 1 year # private key in # /usr/local/openssl/newkey.pem # remove the pass phrase from newkey.pem # to stop server requesting password on load openssl rsa -in newkey.pem -out keyout.pem # CAUTION: this file contains a private key and should be # given read only permissions for the user # move and rename as required for the server # both files newcert.pem and keyout.pem are required # for example for apache SSLCertificateFile /path/to/newcert.pem SSLCertificateKeyFile /path/to/keyout.pem # examples for OpenLDAP TLSCACertificateFile /path/to/cacert.pem TLSCertificateFile /path/to/newcert.pem TLSCertificateKeyFile /path/to/keyout.pem
This is the simplest (one command) way to create a single X.509 certificate that may be used as both as a server and a root (CA) certificate. This certificate, because it is self-signed (and the CA:True field is present), can be imported into browsers and other client software as a root (CA) certificate. The DN requested in this sequence references the server that this certificate is being generated for. In particular the CN should define the host service, such as, www.example.com and not the host name of the computer. Thus, if a web service is addressed externally as https://www.example.com but runs on a host called webserver.example.com, CN=www.example.com should be used. The following shows the standard OpenSSL dialog, values in #description# should be replaced with the required value, for example, #server-name# should be replaced with the valid server name being authenticated, say, www.exmple.com or ldap.example.com.
Note: If a certificate suitable for multiple server name use, for example example.com and www.example.com or www.example.net is required follow this procedure instead.
cd /etc/ssl openssl req -x509 -nodes -days 1059 -newkey rsa:2048 \ -keyout testkey.pem -out testcert.pem Generating a 2048 bit RSA private key .....++++++ ..................++++++ writing new private key to 'testkey.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:#your-country-code# State or Province Name (full name) [Some-State]:#your-state-county-province# Locality Name (eg, city) :#your-city# Organization Name (eg, company) [Internet Widgets Pty Ltd]:#your-organization-name# Organizational Unit Name (eg, section) :#optional# Common Name (eg, YOUR name) :#server-name# Email Address :. # creates testcert.pem as certificate # and testkey.pem as unencrypted private key # which should immediately be given # read only access to user # chown user:group testkey.pem # chmod 0400 testkey.pem # move and rename as required for the server # both files testcert.pem and testkey.pem are required # e.g. for apache SSLCertificateFile /path/to/testcert.pem SSLCertificateKeyFile /path/to/testkey.pem # for OpenLDAP TLS Server (slapd.conf) TLSCertificateFile /path/to/testcert.pem TLSCertificateKeyFile /path/to/testkey.pem # for OpenLDAP TLS Client (ldap.conf) TLS_CACERT /path/to/testcert.pem
Notes: -x509 causes it to self sign as a root CA. -nodes suppresses the pass phrase dialog. -days 1059 provides a 2 year 329 day certificate.
<ouch> Readers may wonder why any sane person would want to create a certificate valid for 2 years and 329 days. There are two reasons. First, it's possible, so why not. Second, observant readers will have noted that 3 years is 1095 days not the 1059 used in the tests. In short, when running the intial tests we incorrectly transposed the 5 and 9 (put it down to age, eyesight or stupidity as you choose) and rather than rerun the tests with 1095 we let the 1059 stand and have come up with this crummy justification instead. Finally, since the current recommendation for 2048 bit keys suggest they will remain valid until 2030 you could sensibly push the value to (currently, in 2013) -days 6205 (17 years, minus leap year adjustments).</ouch>
If you are going to generate multiple certificates for use, say, with an internal system then it is worth investing some time and effort. Having tried this using multiple methods this is, IOHO, the simplest. It uses the standard CA.pl script to establish the CA which initialises a bunch of directories and files that are otherwise a serious pain to set up but then uses openssl commands to generate CSRs and sign certificates since this provides greater control over variables and is, relatively, painless.
Location and Preparation Optional to save some typing. Decide where you are going to build your certificate repository. For the sake of illustration we will create it in /etc/ssl and that location will be used throughout. Change as required to suit your circumstances. Move the CA.pl script (use locate CA.pl if you can't find it) to /etc/ssl/CA.pl or wherever you are going to create the certificate repository since we will edit this file. We also rename the script to ca.pl due to a perverse loathing of the shift key but assuming you don't share our pathological characteristics you can substitute CA.pl in the examples.
The files ca.pl (or CA.pl) and /etc/ssl/openssl.cnf have significant impact on the running of both the script and the openssl commands. We made the following edits for convenience to CA.pl (ca.pl) only the changed lines are shown:
# WARNING: You should make and keep a clean copy of both # CA.pl and openssl.cnf before messing with either # root certificate valid for 10 years - matter of choice # but most public CAs provide a root certificate valid until 2028 $CADAYS="-days 3650"; # 10 years # default is $CADAYS="-days 1059"; # 3 years # changes ca directory name $CATOP="./ca"; # default is $CATOP="./demoCA"; # if changed needs corresponding change in openssl.cnf
We also made the following changes in /etc/ssl/openssl.cnf to make life easier. Again, only the changed lines are shown:
# WARNING: You should make and keep a clean copy of both # CA.pl and openssl.cnf before messing with either [ CA_default ] # mirrors directory change in ca.pl dir = ./ca # Where everything is kept # dir = ./demoCA # Where everything is kept (default) # Extension copying option: use with caution copy_extensions = copy # uncomment above directive if multiple DNS name certificates # are required, else leave commented (default) # default certificate validity changed to 3 years # means you can omit the -days option default_days = 1059 # 3 years # default is default_days = 365 # 1 year [ policy_match ] # add this line in the above section # adds L= to issuer and subject DN # otherwise it is omitted - matter of taste localityName = optional [req] default_bits = 2048 # current 2011 - 2030 recommendation # default_bits = 1024 # original file value [ req_distinguished_name ] # change _default values to save typing # edit or add in appropriate place countryName_default = MY stateOrProvinceName_default = STATE localityName_default = CITY 0.organizationName_default = ONE INC organizationalUnitName_default = IT
It is worthwhile checking this file for any other values that you might want to change.
Create Certificate Authority The first command creates a Certification Authority (CA) root certificate and some other files used for maintenance. A public-private key pair is created. The public key is written into the root certificate - /etc/ssl/ca/cacert.pem - the private key into /etc/ssl/ca/private/cakey.pem. The default file format is PEM. The DN details requested will be used to populate the issuer and subject fields of the root certificate and into the issuer field of all subsequent signed certificates and should be customized to suit user requirements. The pass phrase is required and used to protect access to the private key - it will be used on all subsequent certificate signings so it might be useful to remember it:
cd /etc/ssl ./ca.pl -newca CA certificate filename (or enter to create) #ENTER Making CA certificate ... Generating a 2048 bit RSA private key .....++++++ ..................++++++ writing new private key to './ca/private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [MY]: State or Province Name (full name) [STATE]: Locality Name (eg, city) [CITY]: Organization Name (eg, company) [ONE INC]:CA COMPANY NAME Organizational Unit Name (eg, section) [IT]:X.509 Common Name (eg, YOUR name) :CA ROOT Email Address :. Please enter the following 'extra' attributes to be sent with your certificate request A challenge password : An optional company name : Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for ./ca/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: bb:7c:54:9b:75:7b:28:9c Validity Not Before: Apr 15 21:07:36 2008 GMT Not After : Apr 13 21:07:36 2018 GMT Subject: countryName = MY stateOrProvinceName = STATE organizationName = CA COMPANY NAME localityName = CITY organizationalUnitName = X.509 commonName = CA ROOT X509v3 extensions: X509v3 Subject Key Identifier: 54:0D:DE:E3:37:23:FF:2E:E8:03:0A:2C:52:FE:FC:C0:C8:13:72:80 X509v3 Authority Key Identifier: keyid:54:0D:DE:E3:37:23:FF:2E:E8:03:0A:2C:52:FE:FC:C0:C8:13:72:80 DirName:/C=MY/ST=STATE/O=CA COMPANY NAME/L=CITY/OU=X.509/CN=CA ROOT serial:BB:7C:54:9B:75:7B:28:9C X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Apr 13 21:07:36 2018 GMT (3650 days) Write out database with 1 new entries Data Base Updated
A standard directory structure has been created:
ca # cacert.pem (root certificate) # serial (tracks serial numbers) # crlnumber (serial number for CRLs) # index.txt ca/private/cakey.pem # private ca key ca/newcerts # copy of all certs created ca/crl # optional location for CRLs created ca/certs # optional location for certs created
The root certificate created (ca/cacert.pem) is valid for 10 years (3650 days) based on the ca.pl file edit. The root private key (ca/private/cakey.pem is protected by its PEM pass phrase but should still be protected by the lowest permissions possible (defaulted to 0644 which is unnecessarily high). The Challenge Password is a simple password that may be used to guard access to Certificates, CSRs and the subsequent X.509 certificate. Most, if not all public CAs do not want one or the accompanying Optional Company Name and indeed all the examples leave the field blank. If you want to permanently disable the prompts edit /etc/ssl/openssl.cnf:
[ req_attributes ] # comment out all following lines #challengePassword = A challenge password #challengePassword_min = 4 #challengePassword_max = 20 #unstructuredName = An optional company name
Create a certificate signing request (CSR). The requested DN in this sequence will appear in the subject field of the final certificate.
This command may also be used to generate a CSR (Certificate Signing Request) for a public CA and since most CAs do not want a password just hit ENTER at the A challenge password prompt (see notes above about permanently removing the prompts). The optional emailAddress value is also left blank. Mostly because it achieves no purpose in a server certificate and indeed most public CAs request it is left blank.
openssl req -nodes -new -newkey rsa:2048 \ -keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem Generating a 2048 bit RSA private key ...................++++++ ............++++++ writing new private key to 'ca/private/cert1key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [MY]: State or Province Name (full name) [STATE]: Locality Name (eg, city) [CITY]: Organization Name (eg, company) [ONE INC]: Organizational Unit Name (eg, section) [IT]: Common Name (eg, YOUR name) :www.example.com Email Address :. Please enter the following 'extra' attributes to be sent with your certificate request A challenge password : An optional company name :
This creates a new CSR (in /etc/ssl/ca/certs/cert1csr.pem) which must then be signed using the CA's private key and a private key (not secured by a pass phrase - -nodes option - suitable for use in a server application) in /etc/ssl/ca/private/cert1key.pem. The CN value (www.example.com in the example above) is the service name used by the application. It could have been ldap.example.com or any other similar name. Note also that if the normal server access is https://www.example.com this certificate will work - however if the access will also use https://example.com then you need to add a subjectAltName field by using this procedure before creating the CSR (and use ServerAlias directive in the VirtualHost section for Apache). The service name should not be confused with the server's host name. Thus, if a web service is addressed externally as https://www.example.com but runs on a host called webserver.example.com, www.example.com should be used for the CN.
To view the certificate request:
openssl req -in ca/certs/cert1csr.pem - noout -text Certificate Request: Data: Version: 0 (0x0) Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ae:19:86:44:3c:dd:38:df:e2:41:5f:d8:86:19: 69:7e:85:d7:1d:ae:1e:eb:87:b0:5f:fc:f3:db:e3: aa:82:76:d6:42:05:f1:0e:5c:5a:a2:8d:f6:d3:00: 37:04:96:13:06:16:e6:d1:67:14:69:cd:85:df:a7: b3:ac:a2:6c:33:cd:d6:00:3d:24:99:fa:4b:81:07: 0c:b2:5a:fe:06:16:da:34:66:63:78:31:7d:11:5e: 63:de:9e:ee:76:8b:0c:12:af:fb:f2:28:0a:76:5b: 99:20:b8:f7:c0:9c:e8:89:c5:d0:1e:e5:07:c8:bd: 38:c8:52:97:cc:76:c9:c8:2b Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha1WithRSAEncryption 79:f5:20:45:6c:ec:8e:ae:3a:75:70:67:6d:cb:a9:a6:df:80: f1:8f:43:1b:c5:ce:dd:41:19:e9:8e:72:06:d3:05:b8:23:e6: 98:88:3d:a4:96:62:27:e6:6f:af:fd:7a:b9:20:ec:c6:8d:de: 2b:26:5c:a3:b5:0f:20:09:d3:e8:90:71:0f:dd:81:82:83:94: bb:ac:fa:09:42:5c:7a:91:19:9a:4a:98:7c:92:7d:3d:42:d0: 66:2a:87:ff:b5:58:bd:41:08:1f:4f:02:04:4d:ca:75:6c:5b: bd:61:cd:c5:89:7c:e0:0d:dd:50:1f:90:42:5f:d6:a6:31:71: 40:7d
Create and Sign the end-user certificate This takes the input CSR (ca/certs/cert1csr.pem) and creates the end user certificate (ca/certs/cert1.pem):
openssl ca -policy policy_anything \ -in ca/certs/cert1csr.pem -out ca/certs/cert1.pem Using configuration from /usr/local/openssl/openssl.cnf Enter pass phrase for ./ca/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: bb:7c:54:9b:75:7b:28:9d Validity Not Before: Apr 15 22:21:10 2008 GMT Not After : Mar 10 22:21:10 2011 GMT Subject: countryName = MY stateOrProvinceName = STATE localityName = CITY organizationName = ONE INC organizationalUnitName = IT commonName = www.example.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: EE:D9:4A:74:03:AC:FB:2C:FD:43:C7:58:6E:2E:6A:88:BA:65:61:CC X509v3 Authority Key Identifier: keyid:54:0D:DE:E3:37:23:FF:2E:E8:03:0A:2C:52:FE:FC:C0:C8:13:72:80 Certificate is to be certified until Mar 10 22:21:10 2011 GMT (1059 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
The resulting certificate issuer field is from the root certificate (ca/cacert.pem) and the subject field from the CSR. The command line defaults many values from openssl.cnf: the validity period (default_days =), the signing key (private_key =) and the issuer from the root certificate (certificate =). The -policy policy_anything option may be necessary depending on your requirements. It references the policy_anything section defined in the openssl.cnf file which allows any fields in the subject DN certificate to have different values from those in the issuer DN field. If not present it defaults to -policy policy_match which places restrictions on C=, ST= and O= RDN values.
To view the resulting certificate:
openssl x509 -in ca/certs/cert1.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: bb:7c:54:9b:75:7b:28:9d Signature Algorithm: sha1WithRSAEncryption Issuer: C=MY, ST=STATE, O=CA COMPANY NAME, L=CITY, OU=X.509, CN=CA ROOT Validity Not Before: Apr 15 22:21:10 2008 GMT Not After : Mar 10 22:21:10 2011 GMT Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ae:19:86:44:3c:dd:38:df:e2:41:5f:d8:86:19: 69:7e:85:d7:1d:ae:1e:eb:87:b0:5f:fc:f3:db:e3: aa:82:76:d6:42:05:f1:0e:5c:5a:a2:8d:f6:d3:00: 37:04:96:13:06:16:e6:d1:67:14:69:cd:85:df:a7: b3:ac:a2:6c:33:cd:d6:00:3d:24:99:fa:4b:81:07: 0c:b2:5a:fe:06:16:da:34:66:63:78:31:7d:11:5e: 63:de:9e:ee:76:8b:0c:12:af:fb:f2:28:0a:76:5b: 99:20:b8:f7:c0:9c:e8:89:c5:d0:1e:e5:07:c8:bd: 38:c8:52:97:cc:76:c9:c8:2b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: EE:D9:4A:74:03:AC:FB:2C:FD:43:C7:58:6E:2E:6A:88:BA:65:61:CC X509v3 Authority Key Identifier: keyid:54:0D:DE:E3:37:23:FF:2E:E8:03:0A:2C:52:FE:FC:C0:C8:13:72:80 Signature Algorithm: sha1WithRSAEncryption 52:3d:bc:bd:3f:50:92:67:a3:d3:6f:37:a9:3f:89:b5:16:5b: 9c:0d:32:25:32:91:c7:bf:f6:0d:f8:6d:1c:09:45:2f:3f:b9: 18:b7:1c:8d:7c:06:33:ef:ca:e0:92:a3:90:3f:7c:4e:16:87: 67:ae:7c:2c:1a:43:e5:3a:24:d9:c3:7d:cf:bf:eb:01:9d:c1: f0:bb:0f:15:de:d5:9e:42:9d:f8:7f:0d:5b:af:59:80:d1:aa: cc:db:31:1b:d4:7f:f3:f1:71:25:85:c9:8b:78:3e:13:ac:11: 51:35:49:8d:c3:9a:bb:9a:89:2c:ef:7f:90:f9:05:b3:65:98: b8:74
Checking or viewing Certificates Corruption can occur so the certificate can be verified using the following commands:
openssl x509 -in certificate-name.pem -noout -text # display whole certificate openssl x509 -in certificate-name.pem -noout -dates # validity dates only openssl x509 -in certificate-name.pem -noout -purpose # list of all purposes certificate may be used for openssl x509 -in certificate-name.pem -noout -purpose - dates # list validity period and purpose
Importing a self-signed root certificate The PEM format file created in step 2 above (ca/cacert.pem) may be directly imported into MSIE and Firefox to inhibit them from prompting for untrusted certificates.
MSIE: MSIE prefers its certificates to have a suffix of .cer but happily accepts PEM format so a simple rename will solve the problem ca/cacert.pem -> ca/cacert.cer. Copy to some portable media and use MSIE->Tools->Internet Options->Content Tab->click view certificates button->click Import and follow wizard prompts.
In an AD environment the certificate can also be propagated to all users via Group Policy Object (GPO). Load Administrative Tools->Group Policy Manager->Expand domains->Right click on Default Domain Policy and select Edit->Expand Computer configuration-> Expand Windows Settings->Expand Security Settings->Expand Public Key Settings->Right click Trusted Root Certificate Authorities->select Import and follow wizard Prompts.
Firefox Firefox will accept either a .pem or .cer suffix. Tools->Options->Advanced->Encryption Tab->View Certificates->Authorities tab->click import button and select file.
Method 3 creates a simple two certificate chain comprising an end-entity (server) certificate and a root CA certificate. Method 3A explores how we can add to this structure, for reasons best known to ourselves, to create a subordinate CA, perhaps a second root CA and create a whole variety of Cross and Intermediate certificates based on this structure:
Base Setup: Run steps 1 and 2 of Method 3. This simply creates a directory structure and our first root CA. If you have already run the whole of Method 3, none of the file names created in the next steps will clash - so nothing will be lost and your system will not self-destruct. At the end of this process the following directories will have been created:
ca # cacert.pem (root certificate) # serial (tracks serial numbers) # crlnumber (serial number for CRLs) # index.txt ca/private/cakey.pem # private ca key ca/newcerts # copy of all certs created ca/crl # optional location for CRLs created ca/certs # optional location for certs created
Strategy Note: Openssl commands take many of their advanced parameters from the configuration file (openssl.cnf). Up to this point we have suggested that changes should be made to this standard file since they are typically used consistently accross all commands. From this point on this is not the case. Instead, we recommend that you copy and rename the standard configuration file (openssl.cnf) to a new configuration file with an appropriate name (that you can remember) and use the -config filename argument to pick up the appropriate config file based on usage. It's quicker (eventually), less confusing (eventually) and re-useable (always).
Create a subordinate CA:
Create a new directory called, say, subca and subca/private (giving this directory the same permissions as ca/private). This step simply keeps things organized (kinda):
cd /etc/ssl mkdir ca/subca mkdir ca/subca/private # create necessary empty database file for subca signer touch ca/subca/index.txt
Edit openssl.cnf and create a section called [ sub_ca] - it can be anywhere in the file but for convenience we have shown it located above the [ user_certs ] section. The various entries in this section will be used to override the normal options used when a certificate is signed.
# new section [ sub_ca ] basicConstraints=CA:TRUE # alternatively # basicConstraints=CA:TRUE,pathlen:0 # pathlen:0 constrains the subCA to # only sign end-entity certificates # optional entry and string could be # nsComment="Most Trusted Certificate in the World" nsComment="OpenSSL Generated Certificate" # next two are normal for all non-root certificates subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # next line just shows where sub_ca section is positioned in file [ user_cert ]
Create the subordinate CA certificate:
Create a CSR for the subordinate CA and sign it with the root CA certificate:
# NOTE: These steps will use the root CA created in Method 3 step 1 and 2 # create the CSR for the subordinate CA openssl req -new -keyout ca/subca/private/subca1key.pem \ -out ca/subca/subca1csr.pem Generating a 2048 bit RSA private key ...................++++++ ............++++++ writing new private key to 'ca/subca/private/subca1key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [MY]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) [Some City]: Organization Name (eg, company) [My Company Name]: Organizational Unit Name (eg, section) :Certs Common Name (eg, YOUR name) :subCA1 Please enter the following 'extra' attributes to be sent with your certificate request A challenge password : An optional company name : # Notes: # 1. Organizational Unit Name is not important simply descriptive # 2. Common Name is the name to be given to the subordinate CA # now sign this request using the root CA and force the defined extensions # using -extensions sub_ca openssl ca -policy policy_anything -in ca/subca/subca1csr.pem \ -out ca/subca/subca1cert.pem -extensions sub_ca # display the resulting certificate openssl x509 -in ca/subca/subca1cert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: c6:bd:b2:ce:22:bc:4d:57 Signature Algorithm: sha1WithRSAEncryption Issuer: C=MY, ST=Some-State, O=My company name, OU=Certs, CN=Root CA1 Validity Not Before: Dec 9 20:40:18 2011 GMT Not After : Dec 6 20:40:18 2021 GMT Subject: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Certs, CN=subCA1 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a9:f3:02:01:c9:e3:76:e6:dd:cc:ad:d0:2d:6d: 01:b6:27:c8:a0:9c:f3:a0:85:b8:c7:30:56:18:cb: 34:7d:db:b5:e1:9c:8a:72:6a:91:26:52:f9:71:b7: a1:47:ab:68:a0:ae:96:db:f5:e5:5a:fd:a8:4f:2b: 94:57:ab:a3:ea:c7:b9:ab:fd:16:86:36:3e:43:27: ae:9a:c8:3f:92:ad:ec:a4:3b:9d:6d:3b:87:9d:62: b5:bf:75:40:46:5b:69:80:02:db:fe:0d:f7:49:c0: 40:b9:cf:b4:3e:7e:0f:52:c5:12:58:9d:4b:77:41: a0:f8:9d:36:74:e4:f9:47:c1:04:b1:5e:aa:6b:f6: cd:32:ec:91:a3:e6:51:36:9e:b8:9b:fc:00:80:41: c7:2d:4d:8a:e4:b9:46:a9:1c:d4:5c:97:14:57:21: e2:ff:e8:ff:28:53:5e:bb:13:93:43:86:4d:2a:a6: a0:93:8d:2a:61:c0:b6:e8:4e:87:64:de:09:97:66: c8:f7:ae:66:00:e8:47:76:00:80:12:51:f5:da:f0: 82:f0:6c:b3:b1:00:2d:1a:20:5c:32:ea:d3:72:bc: 0c:a6:82:b8:44:f5:96:0b:68:65:a8:d4:31:81:5e: f0:37:71:5d:e3:c7:3d:59:ff:32:32:49:6b:b6:e5: 55:87 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 58:47:30:77:3F:EF:AC:3D:5A:A3:BB:F6:7F:D2:CE:95:08:77:23:A0 X509v3 Authority Key Identifier: keyid:FB:7B:FB:7B:23:87:8B:FC:3D:97:33:11:6B:0D:37:A0:21:8D:E6:CD Signature Algorithm: sha1WithRSAEncryption 43:b5:e2:8d:4d:07:56:45:20:b3:0b:ac:fd:cc:36:c0:3b:df: 86:19:eb:96:9b:4a:e0:b5:e7:41:73:54:84:8f:ea:15:48:35: 69:15:2f:29:0f:90:79:e3:68:e6:08:4d:98:7b:1c:f3:34:14: 1d:4d:21:dc:0a:2c:1b:90:7b:b8:23:1b:9c:48:1a:b5:ba:91: 44:8e:18:05:1c:ee:48:d8:ef:ab:b7:e5:f6:86:98:bf:17:cd: 4b:40:d3:51:d2:cf:c2:43:14:a3:38:9a:72:30:c7:94:64:e3: 93:80:5c:42:31:79:ba:10:34:d0:96:45:7c:59:67:f5:f0:dd: a9:aa:3d:22:97:d2:d2:05:4d:7b:aa:06:27:8a:69:9d:3c:94: 85:95:b6:7d:49:a5:bd:42:90:57:87:af:44:0f:b2:db:98:d0: d6:fd:9f:65:90:70:a2:af:9d:14:34:5d:2a:7b:28:12:37:e7: 76:0c:b0:58:a1:b7:45:6f:d7:26:dc:cb:f2:39:76:7d:08:5c: 22:f9:99:fc:84:89:b5:7c:e0:75:eb:db:2d:18:8d:d9:da:c8: 4d:f5:cd:47:ad:f3:49:7e:fc:96:4c:2e:e3:92:bd:a3:d8:83: 12:2c:a2:7c:eb:dc:45:e0:61:a0:e1:31:b1:03:4b:55:e8:cf: e0:f3:2b:72
The 4 X509v3 extensions are the direct consequence of the -extensions sub_ca argument and override the normal certificate features. If the root CA is required to sign a normal end-entity certificate just omit this argument. Technically, the resulting certificate (ca/subca/subca1cert.pem) is a cross-certificate because both the signer and the certificate being signed have basicConstraints with cA True.
Sign an end-entity certificate with the subordinate CA:
To sign an end-entity certificate using the subordinate CA we first need to copy and save openssl.cnf to another name, say, subca1.cnf. Now make the following edits to subca1.cnf (these changes simply tell openssl where to obtain various files relating to the subCA whereas the standard openssl.cnf will continue to refer to the root CA information):
[ CA_default ] # only values to be changed are shown database = $dir/subca/index.txt # database index file. certificate = $dir/subca/subca1cert.pem # The subCA certificate # the parameter below will cause all certicates from both the root # and the sub CA to use the same numbering sequence # to change copy ca/serial to ca/subca/serial and modify parameter serial = $dir/serial # The current serial number # if you need to keep CRLs separate or leave unchanged crl_dir = $dir/subca/crl # Where the issued crl are kept crlnumber = $dir/subca/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/subca/crl.pem # The current CRL private_key = $dir/subca/private/subca1key.pem # The subCA private key RANDFILE = $dir/subca/private/.rand # private random number file
Now create an end-entity CSR and sign it with the subCA keys:
# create CSR openssl req -new -nodes -keyout ca/private/user1key.pem \ -out ca/certs/user1csr.pem # sign it with the subCA key by using -config subca1.cnf openssl ca -policy policy_anything -in ca/certs/user1csr.pem \ -out ca/certs/user1cert.pem -config subca1.cnf # print the resulting certificate openssl x509 -in ca/certs/user1cert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: c6:bd:b2:ce:22:bc:4d:58 Signature Algorithm: sha1WithRSAEncryption Issuer: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Certs, CN=subCA1 Validity Not Before: Dec 9 21:06:43 2011 GMT Not After : Dec 6 21:06:43 2021 GMT Subject: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Server, CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c3:f4:dc:07:08:30:3a:3d:72:3e:71:e2:8f:c8: 42:a4:00:6c:9a:e4:5d:fd:3e:28:e0:90:84:1f:10: 3d:c1:f5:22:88:82:52:2b:c3:b5:68:a7:cc:6a:04: 60:77:cc:ac:e1:03:36:53:25:1e:d2:5b:c1:74:1f: ec:87:6a:a3:d7:9b:a7:11:6b:c0:ac:0d:9d:5c:a0: 4d:17:a1:98:c5:c6:1e:3f:b6:17:ab:a3:9c:10:df: bf:cb:82:31:ab:c0:30:5f:58:95:c3:43:72:3a:51: 3d:e0:f4:a1:df:df:64:98:f4:ef:d7:a6:ac:21:20: 0d:2b:21:6e:54:98:c5:2b:d3:46:94:48:03:85:61: a1:bf:27:2d:3c:be:fc:5f:21:d6:82:47:4d:59:48: 3f:f2:7c:c8:6f:04:d5:4f:64:1a:f0:e7:e7:dc:77: 10:7f:1d:82:68:3a:ba:c9:29:79:a9:44:5b:c7:02: c1:59:79:4a:25:c0:e8:f1:89:89:6a:fb:81:6c:2c: 23:b1:2c:cf:ba:e4:ac:ec:dc:f7:92:bd:aa:b1:03: 8a:20:26:06:87:5a:d8:91:7e:4e:88:11:a8:93:b0: d8:e0:81:9e:86:06:94:2e:f6:fd:14:b0:91:28:59: a8:45:fd:c5:d7:a4:04:82:b5:80:a9:28:2b:1e:f2: af:dd Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: B1:5A:23:4E:C8:2B:FD:98:AD:01:7A:CA:73:D3:26:84:75:13:6C:78 X509v3 Authority Key Identifier: keyid:58:47:30:77:3F:EF:AC:3D:5A:A3:BB:F6:7F:D2:CE:95:08:77:23:A0 Signature Algorithm: sha1WithRSAEncryption 50:4b:8e:50:8f:fa:f4:98:ee:37:9e:90:f0:18:af:f4:a4:21: 57:a7:ee:d3:5e:8d:f5:f6:25:d3:84:58:33:cd:b7:ce:88:e4: 9d:5c:f3:6f:3e:b9:b5:eb:8b:4a:48:25:e6:56:5f:da:83:63: d8:a8:8e:9a:dc:6e:d1:ca:d2:69:dc:31:85:3b:93:8e:41:6a: 38:f9:e3:87:47:81:2a:eb:24:c4:03:57:43:1c:5e:2b:07:e2: a4:cb:f1:1d:c0:de:52:8b:f8:a2:59:d7:59:6c:8b:6e:a6:f6: 85:6a:e4:43:05:1c:ad:07:81:db:d7:c7:fe:02:c5:42:b5:89: 76:47:b5:6c:6e:09:d1:82:20:5d:40:93:5b:85:fb:92:c5:92: b6:09:57:0e:b9:36:fa:86:3a:23:89:a6:af:16:b5:0a:15:a7: b1:73:27:38:10:49:f3:ae:83:7f:26:65:51:1f:9f:32:7a:49: 26:cf:d4:ef:9b:18:6f:e1:35:04:30:02:b5:ef:a6:29:0f:1e: b9:d4:82:d1:25:d3:ce:c2:f5:cb:80:5e:bb:7c:95:fc:fc:88: 84:da:0e:36:3a:2b:e7:9e:65:41:f2:7e:b9:fa:a7:4e:04:4d: 3d:97:52:28:1f:a6:9d:2e:54:e5:b8:45:98:33:46:0f:2c:93: ac:58:be:eb
The certificate issuer in this case is subCA1 not root CA1 as when signing the subordinate CA certificate request. To allow chain validation of the end-entity certificate BOTH the root CA certificate (ca/cacert.pem) and the subordinate CA certificate (ca/subca/subca1cert.pem) must be imported into the browser.
Using variations of this technique, a second root CA (root CA2) could be created (another copy of openssl.cnf would be needed clearly), or a second subordinate CA (subCA2 - again with a unique .cnf file). In short, all sorts of ghastly permutations are possible.
If a certificate may be used by a host which has more than one DNS name, say, https://www.example.com and https://example.com or even www.example.net then you need to force the Certificate Signing Request (CSR) to use the subjectAltName field. To do this edit the openssl.cnf file as shown below (only changed lines shown):
# first find the [CA_Default] section [CA_Default] .... # uncomment or add copy_extensions = copy # this causes the ca function to copy the extension fields # from the CSR and should be done on the host which handles # the CSRs to create the certificates # now find [v3_req] section [v3_req] ... # add the following line with host names modified as required subjectAltName = "DNS:www.example.com,DNS:example.com,DNS:example.net" # this should be done on the host that generates the CSR
When you run any CSR request add -reqexts "v3_req" to the arguments only when you need to include the additional subjectAltName fields. While the example above shows 3 names being added in practice it can be any number. Each entry has the format DNS:hostname.domain.name, multiple entries are comma separated and the whole lot are enclosed in quotes. The line following shows the CSR request in Step 3 of Method 3 with the additional argument:
openssl req -nodes -new -newkey rsa:2048 \ -keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem -reqexts "v3_req"
If the -reqexts argument is not added to the CSR a normal single server name certificate is created. This process only works with method 3 above and provides the most flexible approach.
Note: If you are going to produce a number of certificates each of which has different multiple server names then a better strategy may be to simply copy and rename the standard configuration file (openssl.cnf) to something sensible and then use the -config filename argument to pick up each file when required. You can have any number of such config files - as long as you remember their names and functionality.
If you want to create multi-server certificates with Method 1 or 2 then in addition to the above edits, make a further edit to openssl.cnf:
# find the [req] section [req] .... # add or uncomment req_extensions = v3_req
This modification has the effect of adding the subjectAltName fields unconditionally to every CSR.
OpenSSL supports Privacy Enhanced Mail (PEM) as the default format. An X.509 certificate's native format is ASN.1 DER (a binary format). PEM encodes the binary DER in base 64 (RFC 3548) creating a text (ASCII/IA5) version that may be sent by, among other things, mail systems. The format also includes header lines and trailer lines each starting and finishing with precisely 5 dashes to encapsulate the base64 material and provide a human readable indication of its content. PEM files look something like that shown below:
-----BEGIN CERTIFICATE----- MIIDHDCCAoWgAwIBAgIJALt8VJt1eyicMA0GCSqGSIb3DQEBBQUAMGgxCzAJBgNV BAYTAk1ZMQ4wDAYDVQQIEwVTVEFURTEYMBYGA1UEChMPQ0EgQ09NUEFOWSBOQU1F MQ0wCwYDVQQHEwRDSVRZMQ4wDAYDVQQLEwVYLjUwOTEQMA4GA1UEAxMHQ0EgUk9P VDAeFw0wODA0MTUyMTA3MzZaFw0xODA0MTMyMTA3MzZaMGgxCzAJBgNVBAYTAk1Z MQ4wDAYDVQQIEwVTVEFURTEYMBYGA1UEChMPQ0EgQ09NUEFOWSBOQU1FMQ0wCwYD VQQHEwRDSVRZMQ4wDAYDVQQLEwVYLjUwOTEQMA4GA1UEAxMHQ0EgUk9PVDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0YMzbKpykO+O2R9OE0BAMwGSl8M5QAum e8zdgmXklF/AazWqyY9YZSMYV3CF6l3HLoSpvLkjLz4E+78Y15btg0P/54gdSNWz T6YkDd4Te22bt5HZSA4UH4GTBn1M7TCXQBMB+XNtj7PM1ehuazyiHWFYoEbN5ywJ 7M2STtAdOWUCAwEAAaOBzTCByjAdBgNVHQ4EFgQUVA3e4zcj/y7oAwosUv78wMgT coAwgZoGA1UdIwSBkjCBj4AUVA3e4zcj/y7oAwosUv78wMgTcoChbKRqMGgxCzAJ BgNVBAYTAk1ZMQ4wDAYDVQQIEwVTVEFURTEYMBYGA1UEChMPQ0EgQ09NUEFOWSBO QU1FMQ0wCwYDVQQHEwRDSVRZMQ4wDAYDVQQLEwVYLjUwOTEQMA4GA1UEAxMHQ0Eg Uk9PVIIJALt8VJt1eyicMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEA S41UTHVbVdu7Vv1Cg4OoeU+bRghsSTJuZRG+M4T+sG8CEV0uDzxYYGkwDgC9a7Yb Cfh/ea7F1El1Ym1Zj2v3wLhRl1CIRrJSdLFxPNKKoLG5FmVjY4xSGr63PFHqOrtZ NH5lEmZybl+m2frlkjUv9KAvxclZnIFgovdU8YPMDds= -----END CERTIFICATE----- BLAH BLAH BLAH -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,6EF6203EF1A9533A r7LMq15wr1OOmMsD84KyNo+5yY2SfY5DFXhQU+lqVzjLBhHsP3Fa9xpsSgcfPxVz El3/msvQ98BkaMihajEn5f2UxOZcjLCk5lnBHbmXTvOSQhwIBF0/8fUyb1CAyr7c njh4XpwzGBjuIBKhj8uW98tVO2kk/LrFf2rhL97UYNvOj9neFFVt3ODTJw1RiulN nAZCrTmhlfkVEVZDqEEKCVGPnAiWTU8ACMUXj4eJog3eelotFuyZ1JagBpTlzFEX f6uoSk8HBZLItWTxqRuBRVb8jqE2Bhdp9hvvdja9XIrAPGQJ0u2QVw== -----END RSA PRIVATE KEY-----
The text BEGIN CERTIFICATE and END CERTIFICATE in the above may take different values that describe the functionality and format of the material contained within. There may be more than one item in any PEM file (each de-limited by the -----BEGIN -----END sequence) and the file may have other information before, after and between but not within the de-limiters. PEM is defined in RFC 1421 for use by S/MIME (RFC 3850).
# keys key.pem # RSA or DSA key in PEM format key.der # RSA or DSA key in DER format # certificates: # may contain text + private key + cert # in single file or keys may be in separate files # typically if key unencrypted it must be in a separate file cert.pem # PEM format cert.der # DER format cert.p12 # PKCS12 format
PKCS12 (RSA Labs Standard) format are typically used by browsers:
# conversion PKCS12 > PEM openssl pkcs12 -clcerts -nokeys -in cert.p12 -out usercert.pem # extracts certificate only openssl pkcs12 -nocerts -in cert.p12 -out userkey.pem # extracts key only # conversion PEM > PKCS12 openssl pkcs12 -export -out cert.p12 -inkey ./userkey.pem -in ./usercert.pem
List of RFCs relevant to TLS, X.509 certificates and PKI. Most are referred to in the text above. Not exhaustive, but we now update it whenever we update the text or whenever a relevant RFC is published. It should exentually become exhaustive.
|RFC 2986||PKCS #10: Certification Request Syntax Specification Version 1.7. M. Nystrom, B. Kaliski. November 2000. (Format: TXT=27794 bytes) (Obsoletes RFC2314) (Updated by RFC5967) (Status: INFORMATIONAL)|
|RFC 4210||Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). C. Adams, S. Farrell, T. Kause, T. Mononen. September 2005. (Format: TXT=212013 bytes) (Obsoletes RFC2510) (Updated by RFC6712) (Status: PROPOSED STANDARD)|
|RFC 4211||Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). J. Schaad. September 2005. (Format: TXT=86136 bytes) (Obsoletes RFC2511) (Status: PROPOSED STANDARD)|
|RFC 5019||The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, R. Hurst. September 2007. (Format: TXT=46371 bytes) (Status: PROPOSED STANDARD)|
|RFC 5246||The Transport Layer Security (TLS) Protocol Version 1.2. T. Dierks, E. Rescorla. August 2008. (Format: TXT=222395 bytes) (Obsoletes RFC3268, RFC4346, RFC4366) (Updates RFC4492) (Updated by RFC5746, RFC5878, RFC6176) (Status: PROPOSED STANDARD)|
|RFC 5272||Certificate Management over CMS (CMC). J. Schaad, M. Myers. June 2008. (Format: TXT=167138 bytes) (Obsoletes RFC2797) (Updated by RFC6402) (Status: PROPOSED STANDARD)|
|RFC 5273||Certificate Management over CMS (CMC): Transport Protocols. J. Schaad, M. Myers. June 2008. (Format: TXT=14030 bytes) (Updated by RFC6402) (Status: PROPOSED STANDARD)|
|RFC 5274||Certificate Management Messages over CMS (CMC): Compliance Requirements. J. Schaad, M. Myers. June 2008. (Format: TXT=27380 bytes) (Updated by RFC6402) (Status: PROPOSED STANDARD)|
|RFC 5746||Transport Layer Security (TLS) Renegotiation Indication Extension. E. Rescorla, M. Ray, S. Dispensa, N. Oskov. February 2010. (Format: TXT=33790 bytes) (Updates RFC5246, RFC4366, RFC4347, RFC4346, RFC2246) (Status: PROPOSED STANDARD)|
|RFC 5878||Transport Layer Security (TLS) Authorization Extensions. M. Brown, R. Housley. May 2010. (Format: TXT=44594 bytes) (Updates RFC5246) (Status: EXPERIMENTAL)|
|RFC 5912||New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX). P. Hoffman, J. Schaad. June 2010. (Format: TXT=216154 bytes) (Updated by RFC6960) (Status: INFORMATIONAL)|
|RFC 5967||The application/pkcs10 Media Type. S. Turner. August 2010. (Format: TXT=10928 bytes) (Updates RFC2986) (Status: INFORMATIONAL)|
|RFC 6066||Transport Layer Security (TLS) Extensions: Extension Definitions. D. Eastlake 3rd. January 2011. (Format: TXT=55079 bytes) (Obsoletes RFC4366) (Status: PROPOSED STANDARD)|
|RFC 6125||Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). P. Saint-Andre, J. Hodges. March 2011. (Format: TXT=136507 bytes) (Status: PROPOSED STANDARD)|
|RFC 6176||Prohibiting Secure Sockets Layer (SSL) Version 2.0. S. Turner, T. Polk. March 2011. (Format: TXT=7642 bytes) (Updates RFC2246, RFC4346, RFC5246) (Status: PROPOSED STANDARD)|
|RFC 6402||Certificate Management over CMS (CMC) Updates. J. Schaad. November 2011. (Format: TXT=66722 bytes) (Updates RFC5272, RFC5273, RFC5274) (Status: PROPOSED STANDARD)|
|RFC 6712||Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP). T. Kause, M. Peylo. September 2012. (Format: TXT=21308 bytes) (Updates RFC4210) (Status: PROPOSED STANDARD)|
|RFC 6960||X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 2013. (Format: TXT=82037 bytes) (Obsoletes RFC2560, RFC6277) (Updates RFC5912) (Status: PROPOSED STANDARD)|
|RFC 6961||The Transport Layer Security (TLS) Multiple Certificate Status Request Extension. Y. Pettersen. June 2013. (Format: TXT=21473 bytes) (Status: PROPOSED STANDARD)|
|RFC 7027||Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS). J. Merkle, M. Lochter. October 2013. (Format: TXT=16366 bytes) (Updates RFC4492) (Status: INFORMATIONAL)|
|RFC 7030||Enrollment over Secure Transport. M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed.. October 2013. (Format: TXT=123989 bytes) (Status: PROPOSED STANDARD)|
|RFC 7091||GOST R 34.10-2012: Digital Signature Algorithm. V. Dolmatov, Ed., A. Degtyarev. December 2013. (Format: TXT=39924 bytes) (Updates RFC5832) (Status: INFORMATIONAL)|
|RFC 7093||Additional Methods for Generating Key Identifiers Values. S. Turner, S. Kent, J. Manger. December 2013. (Format: TXT=7622 bytes) (Status: INFORMATIONAL)|
|RFC 7250||Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen. June 2014. (Format: TXT=38040 bytes) (Status: PROPOSED STANDARD)|
|RFC 7251||AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS. D. McGrew, D. Bailey, M. Campagna, R. Dugal. June 2014. (Format: TXT=18851 bytes) (Status: INFORMATIONAL)|
The Page modified date at the foot of this page is always correct.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C standards compliant browser such as Firefox