Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

• master

Tags

Creating_a_CA.mdwn

A Certificate Authority (CA) signs certificates, marking them as authenticated. In other words, a CA signature on a certificate says “you can trust the owner of this certificate”. If you’re used to visiting a certain website which your browser trusts, and one day you visit and get a security warning, there’s a chance you’re viewing a clone of the real website, made by a scammer, maybe in hope to get your private account details. Without server authentication, you wouldn’t notice.

I’m not saying SSL is the perfect solution to the problem, or a solution I would design or spread if it was up to me, but I assume you have your reasons to use it (and so do I).

For large-scale use of certificates, i.e. large CAs, it is a good idea to create sub-CAs. These sub-CAs manage their own certificates. It allows responsibility to be delegated to other people and teams, each managing the certificates related to its area/domain. With TinyCA, setting up sub-CAs is quite easy, and the tutorials listed in [[Useful Links]] can help.

However, for small-scale use it is not necessary. This guide is based on home server experience and is focused on small home/community servers. For those, it’s easier to have a single CA which signs one certificate per service. One for the website, one for Jabber server and so on. The number of users and services will probably be small enough to make this approach work well.

When running TinyCA for the first time (or any other time, until you create a CA), it will automatically open the Create CA dialog:

[[!img 1.1-create-ca-blank.png class=“center”]]

Now fill in the details.

• Name: You can make this the same as data (I’m not sure it has to me the same, but some sources say it does and I didn’t test to see whether it’s true).
• Data: Choose a name which refers to yourself, or to your community, or to your organization - whoever is going to be represented digitally by the CA. I think it’s better not to mention a specific website/resource in this field, because it should represent an entity (person, community, etc.) and not a specific resource (server, location, URL, etc.).
• Password: Make it long and hard to guess. You’ll need it only when creating new certificates, which won’t happen very often. You can write down the password and keep it somewhere safe - then you don’t need to worry about forgetting it, and it can be longer.
• Country, organization, etc.: Fill if you want to. It’s not critical. A CA can be managed by people from different countries, so the location you specify there isn’t something people should rely on anyway.
• E-mail address: People will probably find a way to contact you through your website or service etc., but it doesn’t hurt to have a real e-mail address in the certificate.
• Valid for: I’m not an expert, but I suppose having a long validity is okay. I saw the number 7300 (20 years) in other places. You can keep the default (10 years) if you want.
• Keylength, digest: Use the default values.

Here’s an example:

[[!img 1.2-create-ca-filled.png class=“center”]]

When you’re done, click OK. The CA Configuration window will appear.

• Key Usage: Leave the default value.
• Non/critical: I read about it a bit. I’m still not sure I understant what it does, but it seems that critical is the recommended common value used. If you know more, please share the knowledge :-)
• nsCertType: Change to “SSL CA, S/MIME CA, Object Signing CA”.
• subjectAltName: Leave the default value.
• authorityKeyIdentifier: Leave the default value.
• basicConstraints: Leave the default value.
• issuerAltName: Leave the default value.
• nsComment: I’m not an expert, but it seems to be just a comment and its value isn’t significant. Enter anything you wish, or leave the default.
• nsCaRevocationUrl, nsRevocationUrl: Address on the web where the certificate revocation list is accessible to clients. To determine if a certificate is valid, this list will be consulted to check if a certificate has been revoked. This cannot be changed after the creation of the CA, so you need to choose the location now. You can put the revocation list there later, but make sure the URL is valid and that you’ll really be able to make the list accessible through it.
• nsCaPolicyUrl, nsPolicyUrl: A webpage where people read about the policy of the CA, and any certificate use policy you may have. You can write the actual document later, but you must set the web address now. Make sure you’ll really be able to put the webpage on that address.

Here’s an example:

[[!img 2-ca-config.png class=“center”]]

When you’re done, click OK. The CA will be created you will be presented with the main TinyCA window, containing the CA details. It will look like this:

[[!img 3-ca-created.png class=“center”]]