24

I need to create my own CA for an intranet and unfortunately it seems there's no good answer about this on Security.SE.

There are many resources online about this, but all of them are different and some use outdated defaults (MD5/SHA1, etc) which doesn't seem that trustworthy. There are also hundreds of different variations of openssl.cnf, ranging from a 10-line file to the enormous one that came by default with my distribution.

I would like a canonical answer about setting up a simple CA for issuing server certs and client certs.

Apparently it seems some people still don't understand that I'm not some large company where a CA compromise causes billions worth of losses and can't be mitigated easily so let me explain a bit better why I need the CA :

  • multiple servers connected via insecure links (the Internet) need to communicate securely.

  • I need a way to identify myself to those servers in order to perform administrative tasks, without going back and forth to my password manager every 10 seconds.

  • no other CAs than mine should be able to impersonate any of the servers, no matter how unlikely (but possible) that is.

There. My own PKI and a cert installed on each machine seems to fit the needs perfectly. One of the software I use also requires the use of a PKI, so just using self-signed certificates isn't an option.

To compromise the PKI someone would need to compromise my work machine, and if that's done then the attacker can already do quite a bit of damage without even touching the PKI (as I would be logging in via SSH to the server from this machine anyway). That is a risk I'm accepting to take, and this PKI doesn't add any more risk than what there is already.

  • 4
    echo "Abandon all hope, ye who enter here." – Tom Leek May 15 '15 at 14:22
  • 16
    @KristoferA It's for an intranet, it's more than reasonable to create your own CA for a corporate network. – RoraΖ May 15 '15 at 17:31
  • 4
    By the way, what's up with the migrations to Superuser or ServerFault ? Isn't usage of OpenSSL perfectly on topic here ? – user42178 May 16 '15 at 12:19
  • 2
    "...a self signed cert is a certificate signed by an authority not known to most systems." No. A self-signed certificate is one in which the public key, policy attributes and identity attributes have been signed by the private key corresponding to the public key bound by the signature. While it has nothing whatsoever to do with whether the cert comes from a known source, it is true - by definition - that all root certs are self-signed. The difference is that a root cert is enabled for signing but not for encipherment which makes it useless as a personal cert for an app or server. – T.Rob May 22 '15 at 1:39
  • 2
    What André is saying is that the software involved specifically disallows self-signed certs as personal certs and that both the client and server certs must share a common CA. While these are unusual requirements, they are perfectly valid. However, what is being requested is more about policy such as "the root cert path length must not be greater than x" and "the personal cert must contain the isCA=No flag and a path length of zero." Sadly, policies on which most of the trust in the system are based, such as revocation, namespace hygiene and root security, aren't addressed in openssl.cnf. – T.Rob May 22 '15 at 1:49
33
+500

If your infrastructure is tiny, much of the details of running a CA (e.g. CRLs and such) can probably be ignored. Instead, all you really have to worry about is signing certificates.

There's a multitude of tools out there that will manage this process for you. I even wrote one many years ago. But the one I recommend if you want something really simple is easy-rsa from the OpenVPN project. It's a very thin wrapper around the OpenSSL command-line tool. If you're going to be managing a LOT of certificates and actually dealing with revocation and stuff, you'll want a much more complex and feature-complete utility. There are more than enough suggestions already provided, so instead I'll just stick with the basics of what you're trying to accomplish.

But here's the basic procedure. I'll explain it with OpenSSL, but any system will do.

Start by creating your "root" CA -- it'll be a self-signed certificate. There are several ways to do this; this is one. We'll make ours a 10-year cert with a 2048-bit key. Tweak the numbers as appropriate. You mentioned you were worried about hashing algorithm, so I added -sha256 to ensure it's signed with something acceptable. I'm encrypting the key using AES-256, but that's optional. You'll be asked to fill out the certificate name and such; those details aren't particularly important for a root CA.

# First create the key (use 4096-bits if that's what floats your boat)
openssl genrsa -aes256 -out root.key 2048

# Then use that key to generate a self-signed cert
openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256

If you encrypted the key in the first step, you'll have to provide the password to use it in the second. Check your generated certificate to make sure that under "Basic Constraints" you see "CA: TRUE". That's really the only important bit you have to worry about:

openssl x509 -text < root.cer

Cool. OK, now let's sign a certificate. We'll need another key and this time a request. You'll get asked about your name and address again. What fields you fill in and what you supply is up to you and your application, but the field that matters most is the "Common Name". That's where you supply your hostname or login name or whatever this certificate is going to attest.

# Create new key
openssl genrsa -aes256 -out client1.key 2048

# Use that key to generate a request
openssl req -new -key client1.key -out client1.req

# Sign that request to generate a new cert
openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key  -sha256 -CAcreateserial

Note that this creates a file called root.srl to keep our serial numbers straight. The -CAcreateserial flag tells openssl to create this file, so you supply it for the first request you sign and then never again. And once again, you can see where to add the -sha256 argument.

This approach -- doing everything manually -- is in my opinion not the best idea. If you're running a sizable operation, then you'll probably want a tool that can keep track of all your certificates for you.

Instead, my point here was to show you that the output you want -- the certificates signed the way you want them -- is not dependent on the tools you use, but rather the options you provide to those tools. Most tools can output a wide variety of configurations, both strong and weak, and it's up to you to supply the numbers you deem appropriate. Outdated defaults are par for the course.

  • It's important to note that when you sign a client certificate it is the public portion only. No private key should be transmitted or generated by the CA. – RoraΖ May 20 '15 at 14:03
  • Could you please expand your answer on creating an intermediate CA cert ? Thanks. – user42178 May 21 '15 at 16:08
  • 2
    @André Intermediate certs are just normal certs with basicConstraints = CA:TRUE set in their extended attributes. Nothing magic, just another certificate. – tylerl May 21 '15 at 16:40
  • @tylerl Dude, you rock. – jdforsythe Apr 11 '16 at 13:05
  • This answer is FANTASTIC and was super helpful, but I have a 2017 update to add. Chrome and others now require the x509v3 subjectAlternativeName extension; otherwise, they consider the certificate invalid, even with a CA root certificate properly installed on the system. I struggled for some time coming up with the right solution. This page was invaluable to me, and solved the last piece of the puzzle for me: cmrg.fifthhorseman.net/wiki/SubjectAltName. IMO, adding the SAN when signing, as opposed to when requesting, is both easier and more like what the public CAs actually do. – Nick Williams Jan 28 '18 at 3:35
5

There is no way to do this simply. there are some tools that can help you to easily get started.

like:

none of them are a full PKI aside from possibly EJBCA but thats not trivial to setup.

  • XCA is a small frontend tool to get a graphical interface to generate,sign and revoke Certificates.
  • EJBCA or Enterprise Java Beans Certificate Authority is a JBOSS / Jetty Webapp that can do the full PKI infrastructare for an enterprise.
  • openssl is the basic command line tool. it can do all the offline bits of a CA but none of the verification (out of the box). you can make your own OCSP Verifiers with it but you have to make the 'online' code for it yourself.

If all you seek is proper openssl config. XCA can help you generate them. (it has a openssl config export feature

  • 1
    EJBCA now has a VM image you can use. Otherwise "not trivial to setup" can be considered an understatement. It is basically a huge ant script that tries to configure the (JBoss) application server which can (and in my case will) break down. – Maarten Bodewes May 21 '15 at 12:17
  • the VM image is or evaluation purposes so I would not recommand it for a production server. – LvB May 21 '15 at 12:33
  • I may look into XCA. EJBCA definitely isn't an option - a web interface adds an unnecessary attack surface and is harder to set up. I definitely prefer using just openssl though. – user42178 May 21 '15 at 16:10
  • 1
    @André as regards EJBCA, it can be used from the command line too, so you won't have to expose the web interface. But it's an enterprise-level thing and probably overkill for your purposes (and I say this as someone who makes a living working with it). – Jenny D May 22 '15 at 7:02
5

If you truly wish to be a CA take heed of the security implications of doing so.

  1. The private key used to generate the root CA for your intranet should literally be locked in a safe. And access to said safe should be physically monitored.
  2. Using a self signed root CA forces your users to not only trust that you are performing due diligence with the safe guarding of keys but to also insert an initially untrusted root can into their certificate chain.
  3. This also breaks OSCP stapling functionality in regards to external verification of the certificate chain which is the reason identity management services exist in the first place.

Quite a few would argue the reasoning behind managing your own CA such as; it is for a corporate intranet where part of our desktop builds include the root ca or it is for a small number of users.

While it isn't necessarily wrong to do it and may afford some benefits it does negate the verification chain that certificate based identity management was built for.

If you do decide to implement your own root ca just make sure you follow the same security practices as any other root ca uses. As a company the last thing you would want happening is for someone to compromise the private key used for your root ca and begin signing certificates for phishing campaigns against your clients.

There are tons of best practices guides available for this, NIST (national institute for standards and technology) is a collaborative group assisting in various standards for computer security topics.

Recommended reading:
Auditing (PDF)
Disaster Recovery (PDF)
Public Key Systems (PDF)
Sans institute regarding smaller PKI deployments

Ok I see you updated your question to be more specific.

Two documents for configuring your openssl.cnf file for CA specifics:

https://www.openssl.org/docs/apps/ca.html

https://www.openssl.org/docs/apps/config.html

I realize this may not be the answer you want but because everyone's environment and requirements are different you are going to have to define a scope for your CA implementation for a good example config.

  • There's no reason your own CA can't do OCSP. Even OpenSSL commandline can do it, and that's about the lowest bar possible. – dave_thompson_085 Aug 5 at 8:52
3

For some good background, please see my presentation How to Build and Operate Your Own Certificate Management Center of Mediocrity. The gist of the presentation is that the thing most required isn't a list of the commands to run, but rather a deep understanding of all the various controls that go into operating a commercial CA, how they interact together, the exact impact of removing any one of them, the cumulative impact of removing several of them, and the mitigating controls necessary to compensate for the reduced security.

This is why there is no "canonical answer about setting up a simple CA." Either you go the whole ISO route, starting with a key signing party, airgapped and vaulted duplicate root certs, multiple intermediate signers, revocation servers, etc., etc., or else have to devise some compromise based on the unique cost/benefit and risk profile the business is willing to accept. Anyone with sufficient skill and experience to make that evaluation by definition doesn't need the cheat sheet. They can parse the correct command syntax based on a deep understanding of the business function to be accomplished and the security primitives used to implement that requirement.

In the presentation are stories from real engagements of shops that went down this road and got it horribly wrong. In some cases my assessment reported that absolutely nothing I can do with your middleware security can possibly overcome the inherent weaknesses of the internal CA. Anyone in the US should realize they probably buy services from at least one of the vendors to which the presentation refers. These are banks, credit unions, health insurers, retailers and more.

Since for the recommendations to be "correct" requires the answerer to make major assumptions about your acceptable risk profiles, and for you to make major assumptions about the degree to which your and their ideas of risk are aligned and in sync, the very proposal is risky on its face. In most such cases the assessment of the suitability of tutorials provided has more to do with the presentation than with the effective level of security resulting from following their procedures. If it is well organized and clearly articulated, this matters MUCH more than whether it is effective. We pick the canonical cheat sheet that looks best to us.

For these reasons I don't believe a credible expert would provide "correct and up to date openssl.cnf files," but rather might at best provide an evaluation process to assess the requirements and the acceptable risk more fully. Since you are betting the business on the result, no credible expert would do this outside the protection of a contract. Any recommendations that you do get would, almost by definition, have to be from an incredible expert. Good luck.

  • 1
    Even for an intranet for internal resources? You might also want to indicate that the presentation is your own. – schroeder May 21 '15 at 4:35
  • 3
    "Even for an intranet for internal resources?" Especially for the intranet since that's where most data breaches occur. "You might also want to indicate that the presentation is your own." I thought I had when describing my experience doing the assessments, but point taken. I've updated it. – T.Rob May 21 '15 at 11:20
1

Follow these instructions to configure a Windows Based CA. Since you are issuing client certificates, be aware that SHA2 hashes aren't supported on XP.

The simple answer is to:

  1. Install AD
  2. Install an Enterprise CA on the Domain Controller
  3. Edit the Certificate Template to issue End User Certificates (set the permission for users to self-enroll, or go to a web page)
  4. Deploy the root certificate public key to all servers that validate users
  5. If the users are on AD, use GPO to enable auto enrollment

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy