This site is now 100% read-only, and retired.

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.


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 and

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

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

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

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


By default - (and 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 and openssl.cnf.

Changes to

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:


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


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

Changes to openssl.cnf

The first change must match the $CATOP variable from - 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/ -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/ -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 * for a wildcard certificate (everything under

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/ -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 dedicated to providing signed certificates for free. However - the 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 ]

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.

apt-get install tinyca

[ Parent ]

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

[ Parent ]

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 ]

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

[ Parent ]

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 ]

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 ]

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 ]

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 ]

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

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 ]

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 ]

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 ]

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

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 ]

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 ]

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 ]

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 file
Delete the CA from the Personal Keys
Import the CA into Opera Authorities from the 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 ]

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

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
you can get a ssl light certificate for 29 Euro ( about 40 dollar ) a year

[ Parent ]

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!

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.


[ Parent ]

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

[ Parent ]

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

[ Parent ]

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 ]

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