Do you use let's encrypt?





2378 votes ~ 13 comments

 

Certificate Authority (CA) with OpenSSL

Posted by chris on Mon 13 Oct 2008 at 22:46

When you need to run a website (https), mail (ssl/tls) or similar over an encrypted link - you need an SSL certificate. This article will explain some of the choices involved, and how to run your own certificate authority (CA).

  1. Use a certificate signed by a certificate authority (CA)
    • will work out of the box for your users
    • All CAs that are recognized by browsers by default are commercial
      • costs money ($150 a year or so)
      • will need to be renewed every year or two
  2. Generate your own self-signed certificate
    • free
    • will require a user approval
    • can be scary for the unexperienced user
Example dialog from Firefox 3 with
a self-signed certificate

So - what's the difference between these certificates?

A commercial certificate is signed by a certificate authority (CA). By signing this they are saying that they believe that you are who you say you are. The browser/application has a list of trusted CA certificates and can check - when the connection is made it will check the signature against this list of trusted CAs.

A self-signed certificate (one that you generate) will need to be installed in all browsers/applications you are going to use it with OR the users will have to approve the certificate each time they visit the site. In addition - when it falls due for renewal - you will have to re-install the certificate on all locations.

Wouldn't it be nice if we could be our own CA?

Well - luckily for us we can. The user will still have to install the CA certificate - but - these generally run for a lot longer than normal certificates (10, 15, 20 years) and - any new certificates issued using the same CA will be recognised as valid.

Overview

In this article we will examine the following

  1. Setting up the CA software from OpenSSL
  2. Generating the CA certificate
  3. Generating CSR (certificate signing request)
  4. Signing a CSR to generate a signed certificate

Setting up

CA.pl and CA.sh

OpenSSL on debian comes with two files that make the job of being a CA much easier. Both live in /usr/lib/ssl/misc - CA.pl and CA.sh

These scripts do the same thing - it's just that one is written in perl - one is a shell script.

In etch - CA.pl has one setting that CA.sh is missing (when generating the CA certificate CA.pl adds -extensions v3_ca to the call - CA.sh in etch is missing this although I believe it to be fixed for lenny). For this reason - we will use CA.pl

However - we need to setup CA.pl and openssl (/etc/ssl/openssl.cnf) before we can use them properly.

Setup

By default - CA.pl (and CA.sh for that matter) together with openssl.cnf are set up so that everything happens in the local directory - with the CA store in ./demoCA. This isn't so very useful. So - let's make some decisions.

  • Our CA certificate will have a life of 10 years
  • Our SSL certificates will have a life of 2 years
  • We will store the CA information in /etc/ssl/ca (alongside the other ssl files).

To do this we need to change both CA.pl and openssl.cnf.

Changes to CA.pl

Locate the variables at the top - DAYS and CADAYS. Change these lines to look like:


    $DAYS="-days 730";     # 2 year
    $CADAYS="-days 3650";  # 10 years

A little further down you will find the variable $CATOP. Change this line to look like:


    $CATOP="/etc/ssl/ca";

One more change - the default CA certificates key is 1024 bits RSA. I would like 2048.

So - search down to print "Making CA certificate ...\n";. The line after that needs changing from

system ("$REQ -new -keyout " .

to

system ("$REQ -newkey rsa:2048 -keyout " .

Changes to openssl.cnf

The first change must match the $CATOP variable from CA.pl - we need to change the dir variable so that it looks like

dir = /etc/ssl/ca

We should also set the default number of days to match $DAYS:

default_days = 730

I personally also change default_bits to 2048

default_bits = 2048

Finally - and this is optional - you can edit any value in the [ req_distinguished_name ] section that ends 'default' - to change the defaults to match your needs. When generating certificates you will be prompted to enter - so these can always be overwritten - but here you can set the ones you use most often.


Generating the CA certificate and storage area

Run the following:

/usr/lib/ssl/misc/CA.pl -newca

  • Press return for the CA certificate file name
  • It will ask for A PEM pass phrase - choose a good one - this protects your CA certificate's key
  • It will ask for certificate details (country etc) - enter whatever is appropriate for you
  • It will then try to create the certificate with the newly signed key (using the openssl.cnf config) - you will have to give the password you entered above

Your new cacert.pem file is now in /etc/ssl/ca/cacert.pem and can be distributed for installation in browsers etc.

Generating certificates

This goes through the following process:

  1. Generate a certificate request
  2. Send this for signing
  3. Receive the signed certificate
  4. Install it

Of course - as your own CA you will be sending it to yourself and signing it yourself.


Generating a certificate request

/usr/lib/ssl/misc/CA.pl -newreq

This will prompt you for the certificate details. The vital point is that the CN of the certificate must be the domain name of the site you wish to secure. You can use *.example.com for a wildcard certificate (everything under example.com).

This will generate a newkey.pem and a newreq.pem. newkey.pem you need to keep for later - newreq.pem you would send off for signing - in this case to yourself - but you could also use it for purchasing a real certificate.


Signing a certificate request

Given a newreq.pem in the current working directory run

/usr/lib/ssl/misc/CA.pl -sign

This will sign the request and generate a newcert.pem with the signed certificate. You will have to enter the password for your CA key which you supplied when creating the CA key, certificate and store.


Installing the certificates

The installation will depend on what software you are using. You will need the newkey.pem and newcert.pem - rename them to something useful - like domainname.key and domainname.cert.

Some software will not accept the extra information in the certificate file - you can strip out everything apart from the lines -----BEGIN CERTIFICATE----- up to and including -----END CERTIFICATE-----.

Note - your certicate's key has a passphrase assigned during the -newreq phase. If you want your software to autostart this won't work - since it prompts for the password. To remove a passphrase:

openssl rsa -in newkey.pem -out newkey.nopass.pem

This will prompt you one last time and then generate a non-passphrase key file that you can use instead.


1 There is a community site at http://www.cacert.org/ dedicated to providing signed certificates for free. However - the CAcert.org root certificate (their CA certificate) is not installed in browsers by default - and would need to be installed by your users. However - this may be good enough for you.

 

 


Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (77.81.xx.xx) on Mon 13 Oct 2008 at 23:28
I'd be curious about tips on how to maintain a list of generated cerificates and publish revocation lists, I noticed some fields for CRL URLs, but i couldn't find any ready to use package for a public CA.

I'd love to create a company-wide CA that has it's certificate installed by default on all machines and use certificates everywhere appropriate, but the perspective of maintaining those is pretty scary without some examples.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (98.220.xx.xx) on Tue 14 Oct 2008 at 03:06
I use tinyca2 because I can never remember all these command line options. If you are only have a few keys and a simple setup it is really helpful.

http://packages.debian.org/lenny/tinyca
http://tinyca.sm-zone.net/

apt-get install tinyca

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by JulienV (90.33.xx.xx) on Tue 14 Oct 2008 at 10:15
[ View Weblogs ]

[ Parent | Reply to this comment ]

TinyCA recommendation
Posted by undefined (192.31.xx.xx) on Wed 15 Oct 2008 at 02:06
ditto on using tinyca; highly recommended.

i got tired of manually verifying fingerprints whenever accepting my self-signed cert on a new system, and fat chance convincing friends & family to do the same, so i became a CA and download the CA public key to install it (as i'm mainly concerned about mitm attacks and replacing a cert text file in-flight is non-trivial). it even eases migration to new keys as the server's private key has to be located on the exposed web server, but the CA cert can be used on a non-internet-directly-accessible system and even kept on external media to further safeguard.

i've even used it to sign/manage java keytool-generated keys (for an openfire installation).

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by dkg (216.254.xx.xx) on Wed 15 Oct 2008 at 16:47
[ View dkg's Scratchpad | View Weblogs ]
I also recommend using TinyCA. It's a very useful tool.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by chris (213.187.xx.xx) on Thu 16 Oct 2008 at 07:32
[ View Weblogs ]
To those using TinyCA - how about an article? Install/Config/Usage ?

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (217.157.xx.xx) on Wed 15 Oct 2008 at 21:38
Are you sure you want to distribute a PKCS12-file? It contains the private key! Anyone can then create theri own certificates and sign them with your CA Root key!

I do not know which file-format to use for distributing the cacert. On Linux I used the PEM-encoded version of the certificate (cacert.pem), but this may not work on other platforms.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by chris (213.187.xx.xx) on Thu 16 Oct 2008 at 07:29
[ View Weblogs ]
That's actually a very good point. I didn't spot that. So - next question is - when I ask my windows friends what format they need and they say PKCS12 - what is the best thing to do? I'm afraid I don't have any windows boxes to test with.

If we can find out that then I'll get the article updated.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (217.157.xx.xx) on Thu 16 Oct 2008 at 22:42
After a bit of testing I have found that the DER-format does the trick: This file type is recognized automatically by Windows, and you can install it into Windows certificate store by double-clicking it. Even Firefox seemed to be able to see the certificate after it was installed into the Windows certificate store. Firefox on Ubuntu also seemed to like the DER-format :-)

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (77.236.xx.xx) on Sun 26 Oct 2008 at 00:12
Sorry to say so, but !!!IF YOU DONT UNDERSTAND SOMETHING, PLEASE DONT WRITE ABOUT IT!!!!! it is simple rule.

if you look on ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf 4.2.2 section. Then open your p12 in some reader (for example Wireshark)... how much knowledge do you need for this? In every book you read "protect your Private Key" and you are giving private key of CA (authority that "everyone" trust) all over for hackers pleasure... It is not a question of your internal servers, it is question of security of all computers that trust this CA (if i have private key of trusted CA, i may sign my own "trusted" bank certificates for man in the middle atacks and so on.

If i may petition withdraw this article, or correct information on it. This article is dangerous from security point of view.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by chris (213.187.xx.xx) on Sun 26 Oct 2008 at 07:55
[ View Weblogs ]

Didn't make it clear in earlier reply - I'm already working on a fix to the article but haven't had time. To be as clear as possible - the point being made here by commenters is correct - do not distribute the PKCS12 certificate. I'm still looking/getting people to test windows certificate handling (PEM/DER) and Opera - will get the article updated as soon as I get that done.

I wouldn't have included PKCS12 if the windows testers I had hadn't asked for it - my bad that I just thought "Oh - OK - I'll convert the PEM for them" without checking further - haven't used PKCS12 myself - everything I use can cope with the PEM format. :(

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (138.62.xx.xx) on Wed 29 Oct 2008 at 09:49
OK. We've removed the reference to the PKCS12 certificates. I still haven't had a chance to sort out what certificates are needed for IE and Opera. Will add that as soon as I get time.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (87.207.xx.xx) on Sat 29 Nov 2008 at 20:15
any tinyca exported .der file is good for IE, just rename the extension to .cer, import it into IE: it's in Internet Options/Content/Certificates/Trusted Root Certificate Authorities then choose import, find your .cer and - it should work now.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (140.90.xx.xx) on Thu 4 Dec 2008 at 02:24
I have to agree with the parent. The article further fails to recognize the threat to users who import the CA certificate: the users now trust you, the CA operator, not to sign a certificate for bankofamerica.com. Your users don't necessarily have the acumen to decide whether trusting you is a good idea. This is especially true in shops where the CA operator also operates the recursive DNS server.

Given the low cost of certificates these days (e.g. $16 from Dynadot for a non-chained cert), running your own CA for anything other than authentication between automated systems is just dumb.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (212.110.xx.xx) on Wed 2 Oct 2013 at 20:44
In light of allegations that some governments have hacked the CA root keys so they can sign certs and implement man in the middle attacks, I'm starting to think having a internal CA that is used for internal / employee access only is a good idea. The only catch is you have to ensure your CA is kept secure so that rogue sites aren't signed to perform man in the middle attacks on systems that trust your CA.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL-Opera Problem
Posted by Anonymous (80.6.xx.xx) on Fri 24 Oct 2008 at 13:23
Chris, I exported the CA that ended up in Peronal Tab using the Opera Export button. Deleted the CA in the Personal Tab. Then Imported in the Authorities Tab and it worked. This was using your der.p12 logic. I was originally confused about the passwords because the prompt from Opera is the same for the pass phase for the private key and the Export password. I usually have them as different words but was typing in the Export password twice instead of the key Pass Phrase then the Export password. I have not gone on to test this with my CLIENT-CERT stuff yet. But at least I now have a CA in the Authotities tab of Opera 9.6.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL-Opera Problem
Posted by Anonymous (138.62.xx.xx) on Fri 24 Oct 2008 at 13:28
Thanks for that - I'll give it a go :)

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL-Opera Problem
Posted by mjre (80.6.xx.xx) on Fri 24 Oct 2008 at 14:20
I can confirm that I can now connect to a secure Tomcat 5.5 server that uses Self Signed certificates using Opera 9.6. I had to convert the CA certificate and the Client Personal certificates using Chris's des.pk12 trick:

openssl pkcs12 -export -in CaOrClient.pem -inkey CaOrClient.key -descert -out CaOrClient.des.p12

Import the Ca.des.p12 into Opera as a personal key.
Export the CA from the Personal keys using Opera's Export button to a x509.ca file
Delete the CA from the Personal Keys
Import the CA into Opera Authorities from the x509.ca file
Import the Client.des.p12 into the Opera Personal store.

Remember that Opera may confuse you with the various password prompts as it did me. You may get 3, the ey Pass Phase, the Export password and the Main Opera security password.

[ Parent | Reply to this comment ]

Solved: Certificate Authority (CA) with OpenSSL-Opera Problem
Posted by Anonymous (78.52.xx.xx) on Wed 5 Aug 2015 at 19:29
Thanks for this post, it saved my Opera 12's live (once again). (Yes, still using v12 in 2015, as it still has some benefits.)
For the search engine, since it took me a bit longer to get here: This also solved my issue with identifying to internal sites with self-signed/own-ca certificates, even with the pfx generated by Windows Server (a 2008 R2 in my case). I had cross-parsed these (both CA and client) through openssl pcks12 (from pfx to pem+key back to p12 as suggested above), although in a second test the client cert worked also with the original pfx file. Seems that the crucial point is the Windows CA part; I have now backed up the intermediate x509.ca for general usage on other clients. Importing this on other systems worked well, as did directly importing the client pfx afterwards.
What is still important with the client cert pfx, it worked well when I included the entire cert chain (i.e. CA public key) into the pfx.
So now, I can finally have both much more secured servers AND Opera.

Hopefully this still helps someone.

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (62.41.xx.xx) on Thu 30 Oct 2008 at 09:11
just a small comment on www.ssl.nu
you can get a ssl light certificate for 29 Euro ( about 40 dollar ) a year

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by jawnsy (72.137.xx.xx) on Thu 30 Oct 2008 at 16:12
You can get free certificates with CAcert, which comes in the ca-certificates package in Debian and probably other distributions. You can also get Organization access to be able to add lots of certificates for the purpose of validating your clients. Just something to think about, and it's totally free!

http://cacert.org

If any of you are looking for certificates and live in the Toronto, ON (Canada) or London, ON (Canada) areas, I can help you get your first Assurance Points.

Cheers!

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (95.28.xx.xx) on Mon 10 Nov 2008 at 22:32
startcom !!!

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (95.28.xx.xx) on Wed 12 Nov 2008 at 09:47
cacert.org !!!

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (92.50.xx.xx) on Wed 10 Dec 2014 at 14:53
Great Tutorial!
Thank you very much for sharing this!

[ Parent | Reply to this comment ]

Re: Certificate Authority (CA) with OpenSSL
Posted by Anonymous (69.165.xx.xx) on Sun 31 May 2015 at 01:06
This page is still the first ranked page when one uses google to search for 'debian certificate authority', so well done.

One issue is that following the instructions here (in wheezy at least), your certificates will be signed with a (weak) SHA1 signature instead of the now recommended and soon to be mandatory SHA256. You can fix this by modifying CA.pl to read:


 } elsif (/^(-sign|-signreq)$/) {
         system ("$CA -md sha256 -policy policy_anything -out newcert.pem " .
                              "-infiles newreq.pem");

that is, add the '-md sha256'.

[ Parent | Reply to this comment ]