Tag Archives: openssl - Page 3

Checking A Remote Certificate Chain With OpenSSL

Posted by on March 14, 2009 1 comment

If you deal with SSL/TLS long enough you will run into situations where you need to examine what certificates are being presented by a server to the client. The best way to examine the raw output is via (what else but) OpenSSL.1

First let’s do a standard webserver connection (-showcerts dumps the PEM encoded certificates themselves for more extensive parsing if you desire. The output below snips them for readability.):

openssl s_client -showcerts -connect www.domain.com:443
CONNECTED(00000003)
--snip--
---
Certificate chain
 0 s:/C=US/ST=Texas/L=Carrollton/O=Woot Inc/CN=*.woot.com
   i:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
-----BEGIN CERTIFICATE-----
--snip--
-----END CERTIFICATE-----
 1 s:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
   i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
-----BEGIN CERTIFICATE-----
--snip--
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Texas/L=Carrollton/O=Woot Inc/CN=*.woot.com
issuer=/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
---
No client certificate CA names sent
---
SSL handshake has read 2123 bytes and written 300 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
--snip--

There’s a lot of data here so I have truncated several sections to increase readability. Points of interest:

  1. The certificate chain consists of two certificates. At level 0 there is the server certificate with some parsed information. s: is the subject line of the certificate and i: contains information about the issuing CA.
  2. This particular server (www.woot.com) has sent an intermediate certificate as well. Subject and issuer information is provided for each certificate in the presented chain. Chains can be much longer than 2 certificates in length.
  3. The server certificate section is a duplicate of level 0 in the chain. If you’re only looking for the end entity certificate then you can rapidly find it by looking for this section.
  4. No client certificate CAs were sent. If the server was configured to potentially accept client certs the returned data would include a list of “acceptable client CAs”.
  5. Connection was made via TLSv1/SSLv3 and the chosen cipher was RC4-MD5. Incidentally, this typically means that the server you’re connecting to is IIS.

But what if you want to connect to something other than a bog standard webserver on port 443? Well, if you need to use starttls that is also available. As of OpenSSL 0.9.8 you can choose from smtp, pop3, imap, and ftp as starttls options.

openssl s_client -showcerts -starttls imap -connect mail.domain.com:139

If you need to check using a specific SSL version (perhaps to verify if that method is available) you can do that as well. -ssl2, -ssl3, -tls1, and -dtls1 are all choices here.2

openssl s_client -showcerts -ssl2 -connect www.domain.com:443

You can also present a client certificate if you are attempting to debug issues with a connection that requires one.3

openssl s_client -showcerts -cert cert.cer -key cert.key -connect www.domain.com:443

And for those who really enjoy playing with SSL handshakes, you can even specify acceptable ciphers.4

openssl s_client -showcerts -cipher DHE-RSA-AES256-SHA -connect www.domain.com:443

The cipher used above should work for almost any Apache server, but will fail on IIS since it doesn’t support 256-bit AES encryption.

  1. The s_client command we’re using opens an interactive socket and does not automatically return to the shell prompt, so remember you will have to hit control-c or type something and hit return to terminate the process. ↩
  2. This example shows an attempted SSLv2 only connection. SSLv2 should be disabled on any web server you control. It has a variety of flaws and has been superseded by SSLv3/TLSv1 for over a decade. ↩
  3. This example expects the certificate and private key in PEM form. You can provide them in DER if you add -certform DER and -keyform DER (OpenSSL 0.9.8 or newer only) ↩
  4. A list of available ciphers can be found by typing “openssl ciphers”, but there are also myriad ways to sort by type and strength. See the ciphers man page for more details. ↩

Re-Signing An Expired CA Certificate

Posted by on March 5, 2009 No comments

On rare occasions you may find yourself with a self-signed internal CA that has expired while you are still using certificates issued from the CA. One potential solution to this problem is to self-sign a new cert with identical fields using the private key from the old certificate.1

You can fill in almost all the fields using the interactive prompt, but to ensure maximum compatibility be sure every field matches exactly. You will also need to set the serial number of the certificate via the -set_serial parameter (openssl takes this argument in decimal form, not hex)2.

openssl req -new -x509 -key previousprivatekey.pem -set_serial 0000 -out newroot.cer

You now have a new root certificate that will work with your previously issued certificates!

  1. In general this is very bad practice, but this article presupposes that you recognize this and it is still necessary. ↩
  2. If you fail to set the serial identically Microsoft OSes will chain the certificate correctly but OpenSSL will fail. ↩

OpenSSL SAN/UCC Certificate Generation

Posted by on February 28, 2009 4 comments

Signing a CSR containing subjectAltName (SAN/UCC) extensions isn’t hard, but can be a daunting challenge for the OpenSSL neophyte. We’re going to use the OpenSSL Self-Signed CA to accomplish this task in two ways.

Pre-Existing SAN CSR

Either you already have a SAN CSR from another source or you generated one using the tutorial from yesterday. Inside your myca.conf file you’ll need to add the following under the [ myca ] section.

copy_extensions	= copy

Now you can simply sign the CSR using the method specified in the self-signed CA post and you’re all set.

Add SAN/UCC Extensions to Existing CSR

To accomplish this add the following to your myca.conf under the [ myca_extensions ] section.

subjectAltName          = @alt_names

Then add this section at the end of the file.

[alt_names]
DNS.1   = test.domain.com
DNS.2   = other.domain.com
DNS.3   = www.domain.net

Set the DNS entries under alt_names to what you want (adding DNS.4 = if you need more, et cetera). Be sure you do not have the copy_extensions directive present in your conf.
Once you have done this you can sign any CSR you choose with the command specified in the self-signed CA article and it will add the specified subjectAltName attributes to the certificate.

Creating a SubjectAltName (SAN/UCC) CSR

Posted by on February 27, 2009 8 comments

SAN certificates (or as Microsoft and others have taken to calling them, Unified Communications Certificates) are rapidly becoming a popular option for securing multiple domains. In fact, Exchange 2007, OCS 2007, and several other products now require UCC to function. However, this certificate type can proffer some advantages beyond that of a wildcard certificate as well. One such advantage is the ability to secure “domain.com”, “www.domain.com”, “domain.net”, and “someotherdomain.com” all within a single certificate.

SAN CSRs cannot be generated using the interactive prompt in OpenSSL so we’ll need to make a conf:

[ req ]
default_bits        = 1024
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
req_extensions     = req_ext # The extentions to add to the self signed cert
 
[ req_distinguished_name ]
countryName           = Country Name (2 letter code)
countryName_default   = US
stateOrProvinceName   = State or Province Name (full name)
stateOrProvinceName_default = Illinois
localityName          = Locality Name (eg, city)
localityName_default  = Chicago
organizationName          = Organization Name (eg, company)
organizationName_default  = Example, Co.
commonName            = Common Name (eg, YOUR name)
commonName_max        = 64
 
[ req_ext ]
subjectAltName          = @alt_names
 
[alt_names]
DNS.1   = test.domain.com
DNS.2   = other.domain.com
DNS.3   = www.domain.net

You will need to set your alt_names section to the FQDNs you wish to use. If you need more simply add “DNS.4 = whatever.com” and so on. Once you have done that, save the file as “req.conf” and then execute openssl!

openssl req -new -nodes -out myreq.csr -config req.conf
Generating a 1024 bit RSA private key
............................................................++++++
..++++++
writing new private key to 'privkey.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) [US]:US
State or Province Name (full name) [Illinois]:Illinois
Locality Name (eg, city) [Chicago]:Chicago
Organization Name (eg, company) [Example, Co.]:Example, Co.
Common Name (eg, YOUR name) []:www.domain.com

You now have a “myreq.csr” and a “privkey.pem” associated with the CSR. You can now submit this CSR to a CA for signing or sign it with your own self-signed CA. A tutorial to perform the latter will be published in a few days!

Code Signing for Mac OS X and Windows

Posted by on February 22, 2009 3 comments

Code signing is rapidly becoming an important part of application deployment on many platforms. On OS X it suppresses the keychain warnings when you update your application and on Windows it can bypass numerous UAC notifications as well as the initial application launch dialog. This can (sometimes drastically) improve the customer experience and reduce friction associated with your application. But how do you actually do it?

You can purchase a code signing certificate from any major CA, but for today we’re going to use the OpenSSL Self-Signed CA we created in a previous article.

First let’s create a code signing certificate (if you purchased a certificate you will not need to perform these steps):

 openssl req -newkey rsa:1024 -nodes -out codesign.csr -keyout codesign.key

This will write out a codesign.key and codesign.csr after you choose the fields you desire. Since we are making a code signing certificate the common name should be your company name. You can also leave the challenge password blank.

Generating a 1024 bit RSA private key
..........++++++
..................++++++
writing new private key to 'req.key'
-----
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) [GB]:US
State or Province Name (full name) [Berkshire]:Illinois
Locality Name (eg, city) [Newbury]:Chicago
Organization Name (eg, company) [My Company Ltd]:End Entity, Inc.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:End Entity, Inc.
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Now that we’ve created the CSR, we need to modify the myca.conf file to flag certificates for code signing. Find this line

extendedKeyUsage = serverAuth

and change it to

extendedKeyUsage = codeSigning

Now we’re all set to sign the certificate.

 openssl ca -batch -config /path/to/myca.conf -notext -in codesign.csr -out /path/to/codesign.cer

At this point we should have a codesign.cer and a codesign.key file and we’re ready for the actual signing process.

Code Signing on OS X

In OS X the codesign binary is used to sign applications. Codesign cannot accept the private key/certificate pair as a command line parameter, so you must place them in your Keychain. To do this you need to convert your CER + RSA private key into a PKCS12 (PFX) file. Luckily there’s already a post here about that, so check out Generating a PKCS12 (PFX) Via OpenSSL for more information.
Once you have it in the proper format, simply double click to import. Now to sign your application:

codesign -s 'End Entity, Inc.' Whatever.app

Inside the single quotes you’ll want to choose the name (CN) of the certificate as seen in Keychain Access.
If you chose to sign the application with a self-signed cert, please note that OS X won’t trust it unless you add the created root to your Keychain. If you do not you will receive this warning:

Whatever.app/: CSSMERR_TP_NOT_TRUSTED

Code Signing XP/Vista/Windows 7

To code sign in Windows you should have an SPC (aka PKCS7/P7B) or CER file along with a pvk formatted private key. To take a standard RSA private key and convert to PVK you should use PVK Tool (Download link is under the conversion tools heading)
Convert your private key to PVK format

pvk.exe -topvk -nocrypt -in codesign.key -out codesign.pvk

Once you have the files in the format you require execute SignTool from a windows command prompt.

 signtool.exe signwizard


And we’re done! If you chose to sign the application with a self-signed cert, please note that Windows won’t trust it unless you add the created root to your certificate store.

AES Encryption Via OpenSSL

Posted by on January 31, 2009 1 comment

If you have ever wanted to encrypt a blob of data for transmission or archival, OpenSSL provides a simple way to accomplish this task without resorting to platform specific tools.
To encrypt1:

openssl enc -e -aes-256-cbc -in filename -out filename.enc

To decrypt:

openssl enc -d -aes-256-cbc -in filename.enc -out filename.dec

The example above uses AES256 in cipher block chaining mode, however there are almost 50 different cipher functions available for encryption. To see a list, just type openssl enc help. I would very seriously recommend staying with well-known and accepted standard ciphers like AES unless you have an explicit need to choose something more esoteric.

  1. You can also add -a to encode to base64 so you can easily send via email or other methods that don’t support binary encoding. ↩