Generating certificates in OpenSSL

After installing OpenSSL I like to add the location of it's bin folder into my windows system path so that I can run the commands from any directory (usually C:\temp\certs).

The genrsa command generates an RSA private key.
openssl genrsa -des3 -out privkey.key 2048
des3 is the cypher used to encrypt the key, this triggers a prompt for the password.
2048 is the size in bits of the key to be generated.


The req command primarily creates and processes certificate requests in PKCS#10 format.
openssl req -key privkey.key -out ca.crt -new -x509
This command takes the private key and creates a public certificate from it, this will prompt you for the certificate information.
If you look at the properties then you will see that the basic information is there, but not the extended information that you normally see.  This is because the extended information is designated by the signing authority.


The x509 utility can be used to sign certificates and requests.
openssl x509 -x509toreq -in ca.crt -out ca.req -sha256 -signkey privkey.key
x509toreq converts the public certificate into a certificate request (aka certificate signing request or CSR).
sha256 specified that the signature algorithm should also be 256 bytes in size (if omitted then default is sha1).
Third party authorities generally only expect you to provide them the contents of the bottom section in the file, between (and including) the tags:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----


SKIP (unless you plan to use a self-signed certificate)
The pkcs12 command allows PKCS#12 files (sometimes referred to as PFX files) to be created and parsed.
openssl pkcs12 -export -des -macalg sha256 -out ca.p12 -inkey privkey.key -in ca.crt
This command takes in the private key and the public certificate then wraps them together into the format that is most commonly used.  The resultant file is what is generally meant when referring to the 'private key' or 'private certificate' because while the privkey.key file is raw private key this file does contain the contents of that file as well as the contents of the public certificate and this is the most commonly used format for the private key.
des indicates the cypher used to encrypt this file, you will be prompted for the password to the key file and then a new password for the p12 (aka pfx) file (not required, may be blank but should only be left blank if your server requires it to be).
macalg sha256 specifies that the MAC digest algorithm should be 256 bytes in size (if omitted then default is sha1).


SKIP (unless you plan to use a self-signed certificate)
This set of commands will generate a pair of files used in the command to sign the certifciate.
echo %RANDOM% > file.srl
echo [ v3_req ] > client.cfg
echo basicConstraints = CA:FALSE >> client.cfg
echo extendedKeyUsage = serverAuth, clientAuth >> client.cfg


SKIP (unless you plan to use a self-signed certificate)
The random number placed in the serial file is sometimes too large, if you get an error then make it a smaller.
openssl x509 -req -in ca.req -CA ca.crt -CAkey privkey.key -CAserial file.srl -out client.crt -extensions v3_req -extensions v3_req -extfile client.cfg
This command uses your p12 to sign it's own certificate request.  While a certificate is not signed by an authority is commonly referred to as 'self-signed' because it would be trusted on it's own face, the result of this command is a certificate that is in fact actually signed and that signer is itself.  The purpose of which is to specify those extended properties that are designated as part of the signing process.
Compare the ca.crt file properties to the client.crt file to see what has been added.


DO NOT SKIP
If signed by a trusted third party, the file they provide will be used in place of client.crt
openssl pkcs12 -export -des -out client.p12 -inkey privkey.key -in client.crt
This will recombined the signed public certificate with the raw private key into a signed p12 file.


This last command is intended to clean up the files that were created and are no longer required (not advisable to run directly in the openssl folder).
del ca.* priv* file.srl client.cfg

SSL for Beginners, A Primer

Overview

The Secure Socket Layer (SSL) is used to encrypt communications between a client and a server.  There are two flavors of SSL one-way aka server-side and mutual aka bi-lateral.  As you might have guessed, mutual SSL makes use, in part, of server side SSL.

Mechanics

When the client establishes a connection with the server the client determines if the communication will occur over SSL.  For example, HTTP is unsecure and HTTPS is HTTP traffic over an SSL connection (really it could be SSL or TLS, but lets not get into that).

First off the client will call the server to open the connection.  They will negotiate to agree on an encryption algorithm (if they can't find one that they both use then you may see 'negotiation' failures).  Then the server will send it's certificate, which the client will validate in the following ways:

1. The server certificate's subject name (or one of it's subject alternative names) must match the hostname requested by the client or you will get a hostname mismatch error.
2. The client must trust the issuer of the server certificate, normally a third party like Verisign, Entrust, etc.  In some cases clients may be configured to trust the specific certificate of the server they are connecting to or trust the certificate by virtue of it's issuer and also require that it have a specific subject DN.  If the server's certificate does not meet the expectations of the client then the error will be something like 'could not establish trust', which is normally corrected by adding the appropriate third party issuer to the client's trusted root authorities list.
3. If the client is configured to check for certificate revocations then it will reach out to the issuer of the server's certificate to verify that it has not been revoked.
4. Of course the certificate must also not be expired.

The difference between the subject name (Subject CN) and the subject DN is that the CN is the name i.e. server.domain.com and the DN looks more like "CN=server.domain.com,DN=domain,DN=com" which will look familiar if you have worked with LDAP.

At this point your server side SSL connection can move forward, however if you are using mutual authentication then the client certificate is the next step.  Some clients may be configured to not send their certificate until they receive an authentication challenge while some servers expect that the clients send their certificates without being challenged and therefore will not send one, this failure mode can be difficult to recognize.  In the layer 7 environment it is fairly easy to see if a request is coming in without being signed by a client certificate, the problem becomes confirming that request is from the client you are troubleshooting and not from someone else.  The incoming IP address of the request will help you with this, unless you are behind a network architecture that is not providing an x-forwarded-for header.

If you are using mutual SSL then the server should validate the client certificate in a similar manner to the way the client validated the server's certificate, the point of which is to restrict traffic to only be accepted from known clients.  The best way to do this is to have a copy of the client certificate's public key on file for the server to use for validation.  You can use the client's issuer and/or the client's subject name (or even more properties), but even if you use the name and the issuer then another certificate with the same name from the same issuer would be able to get in.  I can understand the temptation because this means that you would not have to make any changes when the client renews their certificate, but it is not as secure as the 'shared secret' of an explicit client certificate.

Anatomy of a Certificate

This is important to understand and I have seen a lot of confusion regarding Public and Private key pairs.  When you create a certificate you generate a key which uses a random number and a password of your choosing.  You should then generate a 'Certificate Signing Request' which you hand off to the issuing authority and they give you back your public certificate (cer, crt, or other extension), you can then merge your key with the certificate to get your private certificate.  The process differs greatly from one issuer (signing authority) to another.

Think of the private key like your drivers license or debit card, when combined with your social or pin (the password) someone else can impersonate you and gain access to sensitive information.  In other words, don't give anyone that private key that should not have it.  Even if you don't give them the password; giving anyone else that key compromises it's security.

The public key on the other hand is much more innocuous.  Its more like your drivers license number, without the card itself there is not much they can do beyond confirming that they are being presented with your card when they see it and it lets them know some information about you (which is what the public key is for), but most importantly they cannot use it to impersonate you.

Both server and client certificates have private and public keys.

• The private server certificate gets installed on the server to host the site or service
• The public server certificate is delivered to clients connecting to the secured URL
• The client certificate private key is used to sign requests outgoing to a secured URL
• The client certificate public key is used by the server to verify the signature of the incoming request from the client

A single certificate can be used for both (as well as other) purposes, but the private key would have to be implemented on a client and a server in order to actually act as both.  When you examine the properties of a certificate you can see what it can be used for in the 'enhanced key usage' (multi-value) property.

Trust Relationships

A third party issuer will have a self-signed root authority.  This means that the certificate does not have an issuer, if you trust it that is because you trust who owns it.  As an issuer they can use it to sign other certificates, such as server, client, and intermediate authorities.  For example the third party trusted authority may issue your company a intermediate authority, and then your company could use that intermediate authority to sign your own server and client certificates.  Then when others look at your certificate public key (because you wouldn't be handing out the private keys) they would see your server certificate's trust chain consists of server.domain.com issued by your.intermediate.authority which is issued by third.party.authority.  Then when they have third.party.authority in their trusted root list they can accept the connection to your server.

In reality if they do not have the third party root in their trusted root authorities list and your intermediate authority in their trusted intermediate authorities list then they may not see your trust chain properly while examining your certificate as that information is populated by the local system unless the certificate is configured to send the entire chain with it.  Also, in order for them to trust a certificate that has an intermediate authority they must either have that authority in their trust lists or trust the root authority and have the certificate delivered with it's complete trust chain.

Certificates issued by the trusted third party are trusted by extension because the third party is expected to have performed due diligence in verifying the identity of those requesting that the third party issue certificates to them.  That is really what you are trusting the third party to do when you add their self-signed issuing root into your trusted root authorities list.  Though if there are intermediate authorities you still need them delivered at some point in order to make that connection between the server or client certificate and the trusted root.