Survival guides - SSL/TLS and X.509 Certificates

This is a survival guide to the eye-glazing topic of SSL/TLS and X.509 certificates. These are elements in what is loosely called a Public Key Infrastructure (PKI).

Note: The original guide was more of an aide-memoire for us on how to create and use self-signed certificates and which worked perfectly when we wrote it around 2002. When we had cause to revisit the topic of SSL in 2008 we found the process no longer worked. Sigh.

The current version has been updated to include SSL, TLS, more detail about X.509 and its usage as well as some explanation about 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 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 (maybe) may trust you. But before you shell out all that filthy lucre for a bright, shiny new X.509 (SSL) certificate you might want to know what it does and how it does it. And if your eyes glaze over when people start talking about SSL, security and certificates - start glazing now.

Contents:

• SSL/TLS Protocol Overview
• Encryption - Overview
• X.509 Certificate Overview
• Certificate Protocols (CMP, CRMF, SCVP, OCSP, HTTP)
• X.509 Certificate Format
• X.509 Certificate Revocation Lists (CRLs)
• Process and Trust - CA's and X.509 Certificates
• Example - Create Self-Signed Certificates (OpenSSL)
• Certificate Format Notes

SSL/TLS Protocol

Secure Sockets Layer (SSL) is a Netscape protocol originally created in 1992 to exchange information securely between a web server and a browser. It has gone through various iterations and is now at version 3 (dating from 1995) and used in a variety of client<->server applications. The IETF standardized Transport Layer Security Version 1 (TLS), a minor variation of SSL, in RFC 2246 and Version 1.1 in RFC 4346. In addition a number of extensions are defined in RFC 3546 when TLS is used in bandwidth constrained systems such as wireless networks. When a secure connection is initially established it will, depending on the implementation, negotiate support of the particular protocol from the set SSLv2, SSLv3, TLSv1 or TLSv1.1. Such is power of the name SSL that in many cases what is called SSL is most likely using TLS - for instance OpenSSL supports both SSL (v2 and v3) and TLS (TLSv1) protocols. While there are detail differences between SSL and TLS the following descriptions apply to both protocols. SSL/TLS 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 - SSL Layering.

SSL/TLS 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 SSL/TLS connection. 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, Secure hashes, symmetric and asymmetric cryptographic algorithms. For those not comfortable with these terms they are covered in in this survival guide.

Establishing a Secure Connection

When a secure connection is established using SSL/TLS, for example using HTTPS (on default port 443), an exchange of messages occur between the client - which initiates the connection - and the server. The first set of messages are called the Handshake protocol. The exchange of messages during the Handshake protocol achieves the following objectives:

1. The protocol to be used in the session is established from the supported set (depending on the implementation) of SSLv2, SSLv3, TLSv1, TLSv1.1 - the highest possible will always be used.

2. The server sends authentication information most normally in the form of (wrapped in) an X.509 certificate but other methods are supported by the protocol.

3. A session ID is established so that the session can be restarted if required.

4. The Client and Server negotiate a cipher suite consisting of a key-exchange algorithm, a bulk data encryption algorithm type and a MAC type for the subsequent data session (Record Protocol). The key-exchange algorithm is normally an asymmetric (public-private key) such as RSA or DSA. Asymmetric algorithms are very expensive in resources (CPU) and therefore symmetric ciphers are used for subsequent bulk data encryption (Record Protocol). The key exchange algorithm is used to transfer information from which key(s) can be computed for the symmetric (bulk-data) cipher.

This a very simplified overview and additional data may be exchanged, for instance, the client can be requested to send an authenticating X.509 certificate but the above describes the normal case and is illustrated in Figure 2 below:

Figure 2 - SSL/TLS Protocol Sequences

Notes:

1. The Handshake Protocol negotiates and establishes the connection and the Record Protocol transfers (encapsulates) the data stream such as HTTP.

2. In Figure 2 messages in black are sent in clear, messages in blue are sent using the public key supplied by the server, messages in green are sent using the negotiated bulk-data cipher and are protected by the negotiated MAC.

3. ClientHello: The ClientHello offers a list of protocol versions 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, 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.

   1. Each cipher suite is comprised of a key-exchange algorithm, a bulk cipher algorithm and a MAC (Hash) algorithm.

   2. 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.

   3. 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)
      

      Extensions, defined in RFC 3546, primarily used in wireless networks may be invoked, in a backward compatible manner, at ClientHello. The server may silently ignore any extensions it does not understand.

4. ServerHello: The ServerHello returns the selected protocol version number, cipher suite and compression algorithm. The server sends a 32 octet random value 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.

   Extensions, defined in RFC 3546, primarily used in wireless networks may be invoked, in a backward compatible manner, at ClientHello. The server may respond to those extension it understands and silently ignores any extensions it does not understand.

5. Certificate: The server sends its X.509 certificate which contains the public key of the server and whose algorithm will 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 but an X.509 certificate is the normal method.

6. ServerDone: Indicates the end of the server part of this dialogue sequence and invites the Client to continue the protocol.

7. Client Key Exchange: 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 keys are derived from this master key.

8. ChangeCipherSpec - Client: 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 connections initial state is NULL and hence the message is shown in the diagram as being sent in clear.

9. Finished - Client: 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 server can decrypt and verify this message using its independently computed keys the dialog was successful.

10. ChangeCipherSpec - Server: This message indicates that all subsequent traffic from the server will be encrypted using the negotiated bulk encryption protocol and will also contain the negotiated MAC. Nominally this message is encrypted with the current cipher which in its initial state is NULL and hence the message is shown in the diagram as being sent in clear.

11. Finished - Server: 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 keys the dialog was successful.

12. Record Protocol: Subsequent messages between the server and client are encrypted using the negotiated bulk encryption protocol and include the negotiated MAC.

Note: The random values sent by the client and server and the subsequent pre-master secret all include a two octet time value and consequentially, as in all cryptographic systems, both systems should be using a synchronized time source such as occurs with NTP.

X.509 Certificate Overview

The original ITU-T standard, from which the certificate gets its infamous name, is X.509 - one of the X.500 directory standard suite of standards. The use of X.509 certificates on the Internet is standardized by the IETF with RFC 3280 defining the X.509 certificate format (updated by RFC 4325 and RFC 4630) and RFC 4210 which defines the Certificate Management Protocol (CMP) protocol used to access and process X.509 certificate requests. Finally RFC 3739 defines what it calls a Qualified Certificate which is related to the European Directive on Electronic Signature. 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.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 and quite scary.

An X.509 certificate provides two distinct capabilities:

1. 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 - and specifically the CN (CommonName) RDN (Relative Distinguished Name) of the Distinguished Name. An example of a CN may be a web site address such as CN=www.example.com.

2. The X.509 certificate is digitally signed by a trusted Authority - 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 is described further. The signing Authority may be a Certification Authority (CA), Registration Authority (RA) or some other intermediate authority (a subordinate CA) or it may be a self-signed.

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.

Most of the information in this section focusses on the use of X.509 for validating server communication, X.509 may also be used for other purposes such as in S/MIME which we may get round to when (if) our heads stop hurting.

X.509 Certificate Chaining

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. 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.

The topmost certificate of the signing hierarchy is known as a root certificate, or sometimes a CA certificate. When a certificate is obtained from a server during an SSL/TLS handshake it must be verified by the receiving software all the way to the root or CA certificate including, if appropriate, any intermediate certificates. A root or CA certificate may be 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 chaining process is shown in Figure 3 below:

Figure 3 - X.509 Chaining

X.509 Certificate Usage

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). It is not network address. An X.509 certificate does not contain a URI to obtain any chained certificates via a network interface - but may contain a URI to obtain CRLs. Users of certificates - such as browser or client email software - must have previously obtained the root and, if the certificate is chained, any required intermediate certificates by some out of band or off-line process. Most common CA root certificates are distributed with browsers (and available to their associated client email software) which also have 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 seem to vary from "pay us lots of cash" to a CA audit and other requirements.

When an end user application accesses an SSL/TLS based service the server certificate is obtained during the initial SSL/TLS Handshake dialog. The end user software, such as a browser, will extract the CN RDN of the subject DN field to verify the entity (such as a web server address, for instance, www.example.com) and then use 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 if one is not found) which will authenticate the server supplied certificate. The net result is that the public key contained in the X.509 certificate is safe (is trusted) to be used to communicate with the defined entity.

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 SSL/TLS 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 - and further described in this guide.

Certificate Protocols (CMP, CRMF, SCVP, OCSP, HTTP)

A number of protocols are defined to manipulate certificates and CRLs. The Certificate Management Protocol (CMP RFC 4210) provides protocol methods to manipulate certificates (the format of the certificate messages is defined in RFC 4211). Online Certificate Status Protocol (OCSP RFC 2560 is a protcol for the on-line verification of certificates (and RFC 5019 defines a simplified version). 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 certicates (also provided by CMP). RFC 4387 defines some limited manipulation of X.509 certificates, keys or CRLs over HTTP using a GET method. RFC 4386 defines use of the DNS SRV RR to discover Certificate repositories, and OCSP services.

Certificate Management Protocol (CMP)

The Certificate Management Protocol (CMP) is defined in RFC 4210 and the message format is defined in Certificate Request Message Format (CRMF RFC 4211.

To be supplied.

Server-Based Certificate Validation Protocol (SCVP)

To be supplied.

Online Certificate Status Protocol (OCSP)

The Online Certificate Status Protocol (OCSP) is defined in RFC 2560 and a streamlined, high-throughput, message format is defined in RFC 5019 which in essense sensibly reduces OCSP requests to a single certificate and removes most of the OPTIONAL fields in requests and responses as noted below.

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 scheme identified in the URI of the AIA field of the certificate being validated. The RFC 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)
      reqCert
        hashAlgorithm            AlgorithmIdentifier
        issuerNameHash           Hash of Issuer's DN
        issuerKeyHash            Hash of Issuers public key
        serialNumber             CertificateSerialNumber
        singleRequestExtensions  OPTIONAL
    requestExtensions            OPTIONAL
  optionalSignature              OPTIONAL

Notes:

1. 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.

# response format
OCSPResponse
  responseStatus
    successful        0  --Response has valid confirmations
    malformedRequest  1  --Illegal confirmation request
    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 (1.3.6.1.5.5.7.48.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

Notes:

1. A certStatus of good is defined in the RFC to mean not revoked but additional information may be available in Extension fields.

2. The responseStatus of unauthorized indicates that the client is not authorized to make an inquiry about this certificate (RFC 5019 extends this meaning to indicate the responder has no authoritative information about this certificate).

3. A number of extensions are defined in RFC 2560 and in addition any of the CRL Extensions (RFC 2459) may be included.

4. 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.

5. 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.

X.509 Certificate Format

This section describes, in gruesome - but incomplete - detail, the format and meaning of the major fields within an X.509 certificate.

An X.509 certificate is an ASN.1 structure encoded using the Distinguished Encoding Rules (DER) of X.690 and includes multiple references to globally unique Object Identifiers (OID)..

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):

# 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
# CN = CommonName - typically product name

# 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 bizarre values
# 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 - entity name e.g. www.example.com

# 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

1.2.840.113549.1.1.1

AuthorityInfoAccess = AuthorityInfoAccessSyntax
# multiple AuthorityInfoAccessSyntax elemenst may exist
# each is comprised of:
 accessMethod  = OID
# may take the values:
# 1.3.6.1.5.5.7.48.1 = ocsp
# accessLocation = URI of the CA's OCSP service
# for the issuer CA
# 1.3.6.1.5.5.7.48.2 = caIssuers
# used only if certificate signer is not 
# the root CA
# accessLocation = URI of root CA description

 accessLocation = URI (exptionally an email address 
                       or X.500 DirectoryString)

digitalSignature (0)
nonRepudiation   (1)
keyEncipherment  (2)
dataEncipherment (3)
keyAgreement     (4)
keyCertSign      (5) # indicates this is CA cert
cRLSign          (6)
encipherOnly     (7)
decipherOnly     (8)

cA               TRUE | FALSE
pathLenConstraint   INTEGER

# (O) = OPTIONAL
distributionPoint  DistributionPointName (O)
# points to a structure defined below
reasons            ReasonFlags (O)
cRLIssuer          GeneralNames (O)
# DN of CRL Issuer if not the same as this 
# certificates issuer
# the DN could be used in an LDAP search request

# DistributionPointName is either
fullName                  GeneralNames 
# may contain either a URI 
# e.g. http://crl.example.com
# OR a Protocol name such as HTTP, LDAP, FTP etc. 
# used to obtain the CRL 
# OR
nameRelativeToCRLIssuer 
# RDN appended to issuer DN to get CRL

# The ReasonFlags may take one of the values:
unused                  0
keyCompromise           1
cACompromise            2
affiliationChanged      3
superseded              4
cessationOfOperation    5
certificateHold         6
privilegeWithdrawn      7
aACompromise            8

policyIdentifier   CertPolicyId # OID
policyQualifiers  # multiple values allowed
                  # typically a URI to a text 
                  # statement of policy or just text

otherName                  type=, value= pairs
                           including Kerberos names
rfc822Name                 email me@example.com
dNSName                    host1.example.com
x400Address                If you are into 
                           X.400 mail addresses
directoryName              Alternative DN
ediPartyName               EDI stuff
uniformResourceIdentifier  URI ldap://ldap.example.com
iPAddress                  192.168.0.1
registeredID               OID

1.2.840.113549.1.1.5

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)

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.

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. 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. The CRL contains a list of all revoked certificates and can be of considerable size thus creating, perhaps, an unacceptable overhead to an SSL/TLS initial connection. Further, depending on the CA's policy, the CRL may be updated every hour or 12 hours or daily etc.. All the effort to fetch the CRL file(s) 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 3280 use the interesting 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. A CRL has the following format:

userCertificate      CertificateSerialNumber
revocationDate       Time
crlEntryExtensions   Extensions OPTIONAL

1.2.840.113549.1.1.5

Process and Trust - CA's and X.509 Certificates

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:

1. 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. 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.

2. A user who desires a certificate will review the products of the various Certification 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.

3. 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) and consists of the following data:

   Version	Version 0.
   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: 1.2.840.113549.1.1.1
   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 unstrcuturedName (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.113549.1.1.5 Note: 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.

4. 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).

5. 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.

EV 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:

1. The CA be audited for EV compliance and undergo a yearly audit renewal.

2. 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!

3. CAs follow the practices defined in RFC 3647 which has INFORMATIONAL status.

4. 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 standards version of the RFC MUST)

   1. O - Organization (OID 2.5.4.10) Full legal name of the user organization
   2. businessCategory (OID 2.5.4.15) defines which category of certificate is involved - may be section 5b, 5c or 5d.
   3. C - Country - (OID 2.5.4.6), ST - stateOrProvinceName - (OID 2.5.4.8) and L - localityName - (OID 2.5.4.7) are all defined to be the legal jurisdiction of the business entity
   4. serialNumber (OID 2.5.4.3) business registration number
   5. CN - CommonName - (OID 2.5.4.3) host domain name e.g. www.example.com

5. On-line capabilities (24x7) to verify the status of any EV certificate. In general this is done using the Online Certificate Status Protocol (OCSP) (RFC 2560).

6. EV certificates may be used for server authentication only at this time.

7. EV certificates are recognised definitively by the use of a registered OID (unique for each CA) in the CertificatePolicies field.

Domain Only Certificates

Domain Only Certificates is 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.

Example - Self-Signed Certificates

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 called 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 certificates are pre-installed) by most tools, for example, browsers. A certificate obtained by a browser from a web site and coming from 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 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 the CA is implicit due to the nature of the organization signing the certificates.

The first time a self-signed certificate is presented to a user's SSL/TLS 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 on a user's computer in which case no browser message will be generated.

Process Overview

The following commands were tested with OpenSSL 0.9.8g.

The following sequences use OpenSSL commands to generate a self-signed X.509 certificate that may be installed and used by SSL/TLS 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 (normally /usr/local/openssl/openssl.cnf) 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.

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)™. Option 1: Quick root and server certificate, Option 2: Quick server certificate only, Option 3: Root CA and Multiple certificates.

Option 1: Root Certificate, Server Certificate

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 CA.pl script is used to simplify the process:

cd /usr/local/openssl
./misc/CA.pl -newca
# the DN sequence requested here will be for the CA
# by default this creates a root certificate
# demoCA/cacert.pem and a private key in 
# demoCA/private/cakey.pem
# cacert.pem is valid for 3 years

./misc/CA.pl -newreq
# creates a Certificate Signing Request (CSR)
# the requested DN sequence will be for the 
# server name the only import value is
# CN which should be the web or other server name
# such as www.example.com

./misc/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
# 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
# e.g. for apache
SSLCertificateFile /path/to/newcert.pem
SSLCertificateKeyFile /path/to/keyout.pem

Further explanation and notes. The file demoCA/cacert.pem, which is the root cetificate, can be copied and imported to a browser.

Option 2: Single Server Certificate

This creates and signs a single server certificate that can be used for server testing. This server certificate, because it self-signed (and the CA:True field is present), can be imported into browsers and other software. 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, www.example.com should be used for the CN. Further if the web service can be addressed as both https://www.example.com and the increasingly popular https://example.com then two certificates are required (and incidentally two VirtualHost definitions in Apache).

cd /usr/local/openssl
openssl req -x509 -nodes -days 1039 -newkey rsa:1024 \
 -keyout testkey.pem -out testcert.pem

# creates testcert.pem as certificate
# and testkey.pem as unencypted 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

Notes: -x509 causes it to self sign as a root CA. -nodes suppresses the pass phrase dialog. -days 1059 provides a three year certificate.

Option 3: Root CA and Multiple Certificates

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 method. 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.

1. 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 from /usr/local/openssl/misc/CA.pl 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 subsititute CA.pl in the examples. The above path seems to be consistent across distributions - but use locate CA.pl if you can't find it.

   The files ca.pl (or CA.pl) and /usr/local/openssl/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:

   # root certificate valid for 10 years - matter of choice
   # but many public CAs provide a 20+ year root certificate
   $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 make the following changes in /usr/local/openssl/openssl.cnf to make life easier. Again only the changed lines are shown:

   [ CA_default ]
   # mirrors directory change in ca.pl
   dir = ./ca                 # Where everything is kept
   # default dir = ./demoCA   # Where everything is kept
   
   # default certification 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_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.

2. 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:

   cd /etc/ssl
   ./ca.pl -newca
   
   CA certificate filename (or enter to create) #ENTER
   
   Making CA certificate ...
   Generating a 1024 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 /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: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 /usr/local/openssl/openssl.cnf:

   [ req_attributes ]
   # comment out all following lines
   #challengePassword		= A challenge password
   #challengePassword_min		= 4
   #challengePassword_max		= 20
   
   #unstructuredName		= An optional company name
   

3. 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 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:1024 \ 
   -keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem
   
   Generating a 1024 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 (unsecured - -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 etc. 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 a separate certificate will be required (and a separate Virtualhost definition in 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

4. Create and Sign the end-user certificate This takes the input CSR (ca/certs/cert1csr.pem) and creates the end user certificate.

   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 policy_anything 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
   

5. Importing a self-signed root certificate The PEM format file created in step 2 above (ca/cacert.pem) may be directly imported into the 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.

Certificates Format Notes

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) to 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 a finishing with precisely 5 dashes to encapsulate the base64 material and provide an 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

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.