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.