SSL Certificate Authority.pdf

Where servers, storage and networking combine to form Voltron.

MARCH 1, 2012 12 COMMENTS (HTTP://DATACENTEROVERLORDS.COM/2012/03/01/CREATING‐YOUR‐OWN‐SSL‐CERTIFICATE‐AUTHORITY/#COMMENTS)

SSL (or TLS if you want to be super totally correct) gives us many things (despite many of the recentshortcomings).

Privacy (stop looking at my password)Integrity (data has not been altered in flight)Trust (you are who you say you are)

All three of those are needed when you’re buying stuff from say, Amazon (damn you, Amazon Prime!).But we also use SSL for web user interfaces and other GUIs when administering devices in our control.

When a website gets an SSL certificate, they typically purchase one from a major certificate authoritysuch as DigiCert, Symantec (they bought Verisign’s registrar business), or if you like the murder ofelephants and freedom, GoDaddy. They range from around $12 USD a year to several hundred,depending on the company and level of trust.

The benefit that these certificate authorities provide is a chain of trust. Your browser trusts them, theytrust a website, therefore your browser trusts the website (check my article on SSL trust(http://datacenteroverlords.com/2011/09/25/ssl‐who‐do‐you‐trust/), which contains the best SSL diagramever conceived).

About these ads (http://en.wordpress.com/about‐these‐ads/)

Creating Your Own SSL Certificate Authority (and Dumping Self Signe... http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certific...

1 of 9 10/26/2013 1:28 PM

(http://datacenteroverlords.files.wordpress.com/2012/03/trustchain.png)

Your devices, on the other hand, the ones you configure and only your organization accesses, don’t needthat trust chain built upon the public infrastrucuture. For one, it could get really expensive buying anSSL certificate for each device you control. And secondly, you set the devices up, so you don’t reallyneed that level of trust.

So web user interfaces (and other SSL‐based interfaces) are almost always protected with self‐signedcertificates. They’re easy to create (http://www.madboa.com/geek/openssl/#cert‐self), and they’re free.They also provide you with the privacy that comes with encryption, although they don’t do anythingabout trust. Which is why when you connect to a device with a self‐signed certificate, you get one ofthese:

(http://datacenteroverlords.files.wordpress.com/2012/02/securitywarningie.png)

So you have the choice, buy an overpriced SSL certificate from a CA (certificate authority), or get thoseerrors. Well, there’s a third option, one where you can create a private certificate authority, and setting itup is absolutely free.

OpenSSL is a free utility that comes with most installations of MacOS X, Linux, the *BSDs, and Unixes.You can also download a binary copy to run on your Windows installation (http://www.slproweb.com/products/Win32OpenSSL.html). And OpenSSL is all you need to create your own private certificateauthority.

The process for creating your own certificate authority is pretty straight forward:

Create a private key1.

Self‐sign2.

Install root CA on your various workstations3.


2 of 9 10/26/2013 1:28 PM

Once you do that, every device that you manage via HTTPS just needs to have its own certificate createdwith the following steps:

Create CSR for device1.

Sign CSR with root CA key2.

You can have your own private CA setup in less than an hour. And here’s how to do it.

Creating the root certificate is easy and can be done quickly. Once you do these steps, you’ll end up witha root SSL certificate that you’ll install on all of your desktops, and a private key you’ll use to sign thecertificates that get installed on your various devices.

The first step is to create the private root key which only takes one step. In the example below, I’mcreating a 2048 bit key:

openssl genrsa ‐out rootCA.key 2048

The standard key sizes today are 1024, 2048, and to a much lesser extent, 4096. I go with 2048, which iswhat most people use now. 4096 is usually overkill (and 4096 key length is 5 times morecomputationally intensive than 2048), and people are transitioning away from 1024.

Important note: Keep this private key very private. This is the basis of all trust for your certificates, andif someone gets a hold of it, they can generate certificates that your browser will accept. You can alsocreate a key that is password protected by adding ‐des3:

openssl genrsa ‐out rootCA.key 2048 ‐des3

You’ll be prompted to give a password, and from then on you’ll be challenged password every time youuse the key. Of course, if you forget the password, you’ll have to do all of this all over again.

openssl req ‐x509 ‐new ‐nodes ‐key rootCA.key ‐days 1024 ‐out rootCA.p

This will start an interactive script which will ask you for various bits of information. Fill it out as yousee fit.


3 of 9 10/26/2013 1:28 PM

You are about to be asked to enter information that will be incorporat

into your certificate request.

What you are about to enter is what is called a Distinguished Name or

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

‐‐‐‐‐

Country Name (2 letter code) [AU]:US

State or Province Name (full name) [Some‐State]:Oregon

Locality Name (eg, city) []:Portland

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Overlords

Organizational Unit Name (eg, section) []:IT

Common Name (eg, YOUR name) []:Data Center Overlords

Email Address []:[email protected]

Once done, this will create an SSL certificate called rootCA.pem, signed by itself, valid for 1024 days, andit will act as our root certificate. The interesting thing about traditional certificate authorities is that rootcertificate is also self‐signed. But before you can start your own certificate authority, remember the trickis getting those certs in every browser in the entire world.

For you laptops/desktops/workstations, you’ll need to install the root certificate into your trustedcertificate repositories. This can get a little tricky.

Some browsers use the default operating system repository. For instance, in Windows both IE andChrome use the default certificate management. Go to IE, Internet Options, go to the Content tab, thenhit the Certificates button. In Chrome going to Options and Under The Hood, and Managecertificates. They both take you to the same place, the Windows certificate repository. You’ll want toinstall the root CA certificate (not the key) under the Trusted Root Certificate Authorities tab.


4 of 9 10/26/2013 1:28 PM

(http://datacenteroverlords.files.wordpress.com/2012/02/setuprepo2.png)

However, in Windows Firefox has its own certificate repository, so if you use IE or Chrome as well asFirefox, you’ll have to install the root certificate into both the Windows repository and the Firefoxrepository.

In a Mac, Safari, Firefox, and Chrome all use the Mac OS X certificate management system, so you justhave to install it once on a Mac. With Linux, I believe it’s on a browser‐per‐browser basis.

Every device that you wish to install a trusted certificate will need to go through this process. First, justlike with the root CA step, you’ll need to create a private key (different from the root CA).

openssl genrsa ‐out device.key 2048

Once the key is created, you’ll generate the certificate signing request.

openssl req ‐new ‐key device.key ‐out device.csr

You’ll be asked various questions (Country, State/Province, etc.). Answer them how you see fit. Theimportant question to answer though is common‐name.

Common Name (eg, YOUR name) []: 10.0.0.1

Whatever you see in the address field in your browser when you go to your device must be what youput under common name, even if it’s an IP address. Yes, even an IP (IPv4 or IPv6) address works undercommon name.

If it doesn’t match, even a properly signed certificate will not validate correctly and you’ll get the“cannot verify authenticity” error.


5 of 9 10/26/2013 1:28 PM

Once that’s done, you’ll sign the CSR, which requires the CA root key.

openssl x509 ‐req ‐in device.csr ‐CA root.pem ‐CAkey root.key ‐CAcreat

This creates a signed certificate called device.crt which is valid for 500 days (you can adjust the numberof days of course, although it doesn’t make sense to have a certificate that lasts longer than the rootcertificate).

The next step is to take the key and the certificate and install them in your device. Most network devicesthat are controlled via HTTPS have some mechanism for you to install. For example, I’m running F5′sLTM VE (virtual edition) as a VM on my ESXi 4 host.

Log into F5′s web GUI (and should be the last time you’re greeted by the warning), and go to System,Device Certificates, and Device Certificate.

(http://datacenteroverlords.files.wordpress.com/2012/02/importcert.png)

In the drop down select Certificate and Key, and either past the contents of the key and certificate file, oryou can upload them from your workstation.

(http://datacenteroverlords.files.wordpress.com/2012/02/importcertandkeyf5.png)

After that, all you need to do is close your browser and hit the GUI site again. If you did it right, you’llsee no warning and a nice greenness in your address bar.


6 of 9 10/26/2013 1:28 PM

(http://datacenteroverlords.files.wordpress.com/2012/02/importedcertkeyf5.png)

And speaking of VMware, you know that annoying message you always get when connecting to anESXi host?

You can get rid of that by creating a key and certificate for your ESXi server and installing them as/etc/vmware/ssl/rui.crt and /etc/vmware/ssl/rui.key.

You May Like

FILED UNDER LOAD BALANCING, SECURITY, VIRTUALIZATION, VMWARE

Awfki (@Awfki) says:March 1, 2012 at 7:27 pmThank you for this. I’ve wanted to do this for quite a while but never bothered to look into what wasneeded.

Also, I think “convinced” in “best SSL diagram ever convinced” was meant to be “conceived”. Andyes, it is an awesome diagram.

Replytonybourke says:March 1, 2012 at 9:09 pmThanks, fixed

ReplyRobert Sander says:March 4, 2012 at 10:03 amIf you do not want to remember all the openssl command line arguments you could use a GUI suchas http://xca.sourceforge.net/


7 of 9 10/26/2013 1:28 PM

Replygillespiem says:July 31, 2012 at 12:20 pmGood article (and great graphics), but the title is misleading.

In no way does this dump self‐signed certs as “(and Dumping Self Signed Certs)” claims – bydefinition a self‐signed cert is “signed by the same entity whose identity it certifies”.

You’re simply installing a root certificate soas to prevent clients from prompting you to acknowledgethe certificate isn’t verified. It’s still very helpful, but it’s not dumping self‐signed certs in any form.

Replytonybourke says:July 31, 2012 at 12:29 pmA fair point, but CAs and roots are also “self‐signed”, technically

Replyj says:April 9, 2013 at 6:11 pmThe next step is to self‐sign this certificate.

openssl req ‐x509 ‐new ‐nodes ‐key root.key ‐days 1024 ‐out rootCA.pem

…did you mean rootCA.key?

anyways this looks great, look forward to giving it a try

Replytonybourke says:April 10, 2013 at 8:42 amYup, you’re right. Corrected!

ReplyNeddage says:April 10, 2013 at 1:14 pmGood article. What’s the procedure when the root CA expires? Do you need to update all the otherservers certificates or is there a shortcut? Or should you just give the root CA a lot longer before itexpires, say 5 years?

Replytonybourke says:April 10, 2013 at 1:15 pmYeah, if the root expires, everything needs to be updated. That’s why if you look at rootcertificates in your operating system, they usually expire in 10‐30 years.

ReplyMorris Mojo Jones (@mojo_la) says:July 29, 2013 at 10:18 amHere’s a tip: If you create a CA, don’t store the private key on a github repository.

If I have a group of machines at work that will accept any device certificates signed by my CA, I


8 of 9 10/26/2013 1:28 PM

don’t want someone using that CA key to potentially sign a proxy certificate or some other spoof.

ReplyJulius says:October 1, 2013 at 4:12 pmA little improved security, adapted to post‐Snowden knowledge:‐ Install the absolute latest version of openssl (bypass apt or yum, use source..).‐ Fine commands to use instead of the two mentioned in your article:

# openssl genrsa ‐out /root/rootCA.key 4096 ‐aes‐256‐cbc

# openssl req ‐x509 ‐new ‐nodes ‐key /root/rootCA.key ‐days 3650 ‐out rootCA.pem ‐config /etc/ssl/openssl.cnf

And you can edit the openssl.cnf defaults under [ req_distinguished_name ] to save time..

ReplyAlex says:October 11, 2013 at 10:23 amGood article, I am just missing or not understanding something.

I am in a client server situation.I guess I put the rootCA.pem on the server and the device.crt on the client but that doesnt seemenough to me.Dont I need to create a server certificate, generate a public part, and put that public part in the client?If yes, how do I generate that?

ThanksAlexBut what do I put on the client app?

Reply

Blog at WordPress.com.

The Enterprise Theme.

Follow

Powered by WordPress.com


9 of 9 10/26/2013 1:28 PM

SSL Certificate Authority.pdf

Documents

Transcript of SSL Certificate Authority.pdf