CODEWITHSUNDEEP
securitysslopensslcertificatepki
Siyuan Ren
Siyuan Ren

Reputation: 7844

How to create a CA with openssl *with minimal power*

There are already answers about generating self signed certificate with openssl like this. However, what I want is a certificate that can do nothing but authenticate and encrypt the traffic to predefined websites.

A certificate generated by the following command

 openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

has basic constraint / certificate authority set to YES, meaning that it can be used to sign other certificates. Suppose that my domain is mystackoverflow.com, an attacker who steals my private key would not only be able to MITM the connection to mystackoverflow.com, but also facebook.com or google.com because he can sign forged certificates with the said private key and get trusted by my system.

So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?

Upvotes: 2

Views: 439

Answers (2)

jww
jww

Reputation: 102494

I want is a certificate that can do nothing but authenticate and encrypt the traffic to predefined websites... So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?

There are three parts to this question.

First is how to "authenticate and encrypt [stuff]". That's handled by Key Usage and Extended Key Usage. In particular, bits like digitalSignature (signing key exchange, like Diffie-Hellman), keyEncipherment (key transport, like RSA), serverAuth, etc.

Second is how not to mint certificates. For end entity certificates (i.e., server certificates), you remove the CA=true basic constraint and you remove the keyCertSign bits. You will still need a intermediate CA with the ability to sign end entity certificates because that's where the policy of "this CA can only issue for these names" is applied.

Third is how to apply a policy like "this CA can only issue for these names". Under the IETF's rules for PKIX in RFC 5280, you can do it in the CA certificate with the Name Constraints extension. See section 4.2.1.10 for details.

Under CA/Browser Forum rules, you can do it because they have policy objects. But I don't know how to do it under the CA/B (it may be the same as the IETF).

You have to be careful with the IETF gear. They have extensions, but they don't have policies. So you need to ensure you are working within and existing extension, and not forging new policy. See OID for certificates issued under IETF policy? on the PKIX mailing list for more details.

The CA/B Forum is significant because browsers follow the CA/B Forum rules, and not the IETF. And the CA/B Forum and IETF have different requirements in a few key areas. That's why a certificate created with OpenSSL (which follows IETF guidelines) fails to validate in Browsers (which follow CA/B Forum guidelines).

A certificate generated by the following command: openssl req ...

It used to be how to do it, but its not how to do it today. Today it produces a malformed certificate (which may or may not cause problems, depending on your user agent). For the question you cited, one answer in particular tells you why its incorrect and how to do it.

Upvotes: 2

Steffen Ullrich
Steffen Ullrich

Reputation: 123674

.. an attacker who steals my private key ..

So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?

If you fear that the attacker might steal the key to the certificate and then sign other things with it, then you should not create a self-signed certificate. Instead create first your own CA. Then create a leaf-certificate which can not be used to sign certificates and sign it by your own CA. Once this is done put the private key of the CA far far away (offline or even destroy it if you don't need it to sign more certificates).

With this setup an attacker could still steal the identity of the certificate if it gets its private key. But since this certificate is not a CA itself (unlike normal self-signed certificates) it can not be used to sign new certificates.

Upvotes: 1

Related Questions