SSL/TLS - Distinction between self-signed cert and self-signed CA, and other questions?

Question

I have a small personal website which I wish to serve securely over HTTPS. At the moment I do not wish to use a third party CA to sign my certs. I was reading this document on generating a self-signed cert.

I have three questions.

• The document shows two ways: (1A) Generating your own self-signed cert. and (1B) Generating your own cert/CA and then using the CA to sign your cert.

  I don't understand what the difference between the two is. What is the point of generating your own CA if none of the browsers trusts it (unlike certs signed by Verisign)? Is (1B) used to prevent MITM attacks? If so, should I use (1B) over (1A)?

  Other than managing/revoking multiple certificates (if I use them), a self-signed CA seems pointless?

• I noticed that the doc uses des3 cipher. Would it be possible to use aes-256 cipher instead unless there is a good reason to use des3? (Also how do I do this?)

• This thread made a distinction between using 2048 bit keys and 256 bit keys. I understand what the answer is saying to some degree (that the public (2048 bit) keys are used to encrypt the symmetric (256 bit) keys in order to exchange keys between server and client). But I do not understand how this is applied in the context of the doc. In the doc, I see this line:

  openssl genrsa -des3 -out server.key 4096

  Does this line mean that it's generating a symmetric key (des3), and then generating a public key (RSA 4096 bit)?

Answer 1

A CA certificate is a certificate which is owned by a CA and marked as being suitable for usage as a CA; namely, that it contains a Basic Constraints extension with the "cA" flag set to TRUE.

A self-signed certificate is a certificate which is signed with the private key corresponding to the public key which is in the certificate itself. This means that the certificate was issued by the certificate owner itself, not by somebody else.

A CA certificate can be self-issued; this is the normal case for a root CA. A root CA is a CA which exists by itself and is meant to be trusted a priori (manually included in a Web browser or an OS certificate store) and not by virtue of being issued by another, trusted CA.

Creating a self-signed CA and using it to sign the actual server certificate (option 1B) is useful if you envision to issue several certificates (possibly many) for many servers. With your own root CA (that's what option 1B means), you would just have to insert one certificate manually in all the clients (your self-signed root CA). If you only have a single server certificate to produce, and predict that things will stay that way, then option 1A is as good as 1B, arguably better since it is simpler.

---

The -des3 option is for symmetric encryption of the CA key. That's not bad. There is not enough computing power (or, for that matter, raw power) on Earth to break properly done 3DES encryption. Going to AES-256 would be useless, and it might prove difficult because the OpenSSL command-line tool do not support it out-of-the-box (OpenSSL, the library, includes an AES-256 implementation, but the command-line tools do not given an easy access to it when it comes to symmetric encryption of private key).

---

Digital signatures (that which are applied on certificates) use, by definition, asymmetric keys. Asymmetric keys require a lot of internal mathematical structure, and that structure can be used to weaken them, so they have to be much bigger than symmetric keys in order to achieve a decent level of security. Which is why a good RSA key will have to go to 2048 bits or so, while a 128-bit symmetric key is already rock solid. The line:

openssl genrsa -des3 -out server.key 4096

generates a new asymmetric RSA key pair of size 4096 bits, and stores that in the file server.key. That storage is furthermore protected (encrypted) with 3DES, using a symmetric key derived from the password you type at that point.

The private key includes a copy of the public key. The public key (but, of course, not the private key) will also be part of the certificate: it is first copied into a certificate request (the ".csr" file) and then into the certificate itself.

Answer 2

CA vs. Self Signed Cert

In any PKI installation, the self-signed certificate (CA or end entity - for example a server) must be distributed to all relying parties. For your average user, the well-known, highly trusted public CA systems are deployed automatically. For smaller infrastructures - such as internal corporate environments - an internal CA cert can be automatically packaged in browsers, servers, and other distributions. In all cases, if the cert is self-signed it must be explicitly trusted.

The big diferences are:

• self signed end entity certificate - if you create more than one certificate, EVERY certificate you create must be explicitly trusted at every end point. If a certificate is compromised, the trust must be removed from every end point. It can be done with automated scripts, but it's a lot of work.

• self signed CA -> signed end entity - you must explicitly trust the CA, and then every end entity will be automatically trusted. If you plan to create multiple server certs over any span of time, this will reduce the workload. The trick is, you need a way of verifying revocation if there is any chance of server certificate compromise (which there always is). This is where complexity comes in - CRLs or OCSP are the standard ways to communicate about a compromise, but that means doing more work, not less, to stage and distribute CRLs and (optionally) stage and run an OCSP server. Further more, browsers must be configured to check this - which isn't a default setting.

It has a lot to do with the risks in your system and what you think the lifecycle of your cert issuance and revocation will be.

DES3 vs. AES-256

From openSSL documentation, your options with the command you cited are:

• DES
• DES3
• IDEA

I'd recommend IDEA as the newer algorithm and better practice, but not if any of your systems are not compatible. This can be a real pain - trying to diagnose why you can't use a given certificate and private key can be extremely frustrating and the answers provided by most systems are unclear and difficult to understand.

According to this documentation:

These options encrypt the private key with the DES, triple DES, or the IDEA ciphers respectively before outputting it. If none of these options is specified no encryption is used. If encryption is used a pass phrase is prompted for if it is not supplied via the -passout argument.

This is how the private key is stored and protected within the server.key file. It has nothing to do with how the certificate allows your server to communicate with other systems.

In a regular CA system (OpenSSL can be a little primitive), there is a way to specify how the key can be used for encryption - which can include valid SSL settings, like allowing or enforcing a 256bit session key.

This is not a factor of the key of the certificate (in your example, that's a 4096 bit RSA assymetric key) - it's a factor of what the key pair represented is allowed to do according to the CA and it's associated security policy. This does typically control how an SSL session is set up.

To be clear no SSL session keys are made in the creation of a certificate. Session keys are created and negotiated at the time that a client communicates with a server - long after the certificate is created, signed, and installed.

Answer 3

1. If a company wants to generate their ownCA they can include it into their personel's computers, for instance for trusting internal websites or proxies (in case of inspection of SSL connections).
2. 3 DES is not broken, but AES-Provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192- and 256- bit keys. 3DES is essentially DES encrypted 3 times.
3. RSA is an expensive algorithm and is not really suitable to encrypt every connection with. so what happens is that instead of transmitting everything encrypted with RSA, the server creates a random key made up of 256 bits (you can see this key like a password, just a bunch of random characters, 256 bits of length) and encrypts it with the RSA key and sends it to the other end. From here they both use a symmetric encryption algorithm like AES (which is a lot faster than RSA to encrypt and decrypt data) to transmit data securely.

Answer 4

In order:

The document shows two ways: (1A) Generating your own self-signed cert. and (1B) Generating your own cert/CA and then using the CA to sign your cert.

I don't understand what the difference between the two is. What is the point of generating your own CA if none of the browsers trusts it (unlike certs signed by Verisign)?

Even if your certificate isn't signed by a CA that's trusted by a browser it can be used to encrypt traffic between the client and server. This means you'll get the secrecy you want thanks to the encryption. What you won't get is that little green padlock in your visitors browsers that tells them that your domain ownership has been vetted by a certificate authority. So they won't be able to verify the authenticity of your site (possible MITM) but the communication will be encrypted.

A self signed cert is the root of trust in all certificate hierarchies. Verisign has a self signed cert that's the root of trust for all of the certs that they sign (and it's probably in a bunker somewhere). If you want to be able to play certificate authority (i.e. create more than one certificate and have them all part of the same trust chain) then you should to create a self signed cert and use it to sign the other certificates (see openssl req and openssl x509).

Is (1B) used to prevent MITM attacks?

No. Your (1B) is intended to allow the creation of multiple certificates that are all tied to the same CA just like the author states in the first paragraph. Basically this is an exercise that shows you effectively what a certificate hierarchy is.

If so, should I use (1B) over (1A)?

For a single website you can get away with 1A just fine though doing 1B is a good exercise.

I noticed that the doc uses des3 cipher. Would it be possible to use aes-256 cipher instead unless there is a good reason to use des3? (Also how do I do this?)

Some of the openssl documentation in Linux distros is missing it but you can substitute -aes256 in place of -des3 to use the 256 bit AES instead. Similarly the 192 and 128 bit variants are also available. Check the output of openssl genrsa --help for the list of supported algorithms. As to the proper algorithm selection: so long as the algorithm isn't known to be broken there's little difference. Both AES256 and tripple-DES (des3) are very strong. I generally prefer AES as it's more efficient.

openssl genrsa -des3 -out server.key 4096 Does this line mean that it's generating a symmetric key (des3), and then generating a public key (RSA 4096 bit)?

No. This command causes openssl to create a 4096 bit RSA private key that is encrypted using tripple-DES. You'll be prompted for a passphrase and before you can use this key for any purpose you'll have to decrypt it using the same passphrase. This is intended to prevent use of the key if it's lost / stolen.

Answer 5

Since it seems like you're looking for overview information here I'm going to keep my answer short but feel free to read through the openssl documention

1. A Certificate Authority (CA) is used to sign other certificates to create a web of trust. For example: if you were to get a 3rd party certificate then you would receive a certificate signed by someone else (thwat, verisign, koomodo, etc). These are 'trusted CAs' that a user's browser's key store will be able to verify against. The browser looks at your certificate for YYY.com and if it's signed by a trusted agent and isn't revoked then it accepts it as a good (green lock). If there isn't a trusted CA in the signing chain then there's no way to know if the certificate can be trusted.

2. You should be able to. try openssl genrsa -aes256 -out server.key 4096

3. You're going to have to do a little deeper digging to really understand this topic but at a very high level the private key is used to generate your asymmetric key pair. In the article you reference the section 'GENERATING DSA KEY' shows creating your private key and 'CREATE SELF-SIGNED CERTIFICATE FROM A CERTIFICATE SIGNING REQUEST' shows using that key to sign a csr so that the resulting certificate will be trusted to your CA.

This is REAL quick and dirty review of SSL concepts (I expect to be flamed :) so I highly recommend that you dig deeper if you really want to get your head around SSL. There is a nice little overview of SSL at gavaghan.org that should help to give you a more complete understanding of the technology. A quick google of 'SSL tutorial' or similar should also yield good results.