I am building a mail server on Centos 6.3 and working with OpenSSL to create a self-signed certificate for mail use.
Along the line of learning the 'best' options to use for OpenSSL and dealing with the default SSL virtual host for Apache, I discovered that the localhost cert created (I believe) during firstboot has the X509v3 extensions set as a CA cert (eg basicConstraint CA:TRUE). I was once very involved in PKIX and legal issues on certificate policy. Having the localhost cert being a CA cert, thus allowed to sign other certs, MAY have legal implications in the USofA and EU.
Why was this chosen? Why is not -extensions v3_req used in the certificate creation?
Oh you can see this for yourself with:
openssl x509 -in /etc/pki/certs/localhost.crt -text -nameopt multiline -noout|more
On 01/08/2013 05:07 PM, Gordon Messmer wrote:
On 01/08/2013 11:49 AM, Robert Moskowitz wrote:
Why was this chosen? Why is not -extensions v3_req used in the certificate creation?
Because it has to be able to sign itself?
No. A self-signed cert need not and actually SHOULD not be a CA cert according to PKIX standards.
CA is for signing other certs.
On 01/08/2013 05:07 PM, Gordon Messmer wrote:
On 01/08/2013 11:49 AM, Robert Moskowitz wrote:
Why was this chosen? Why is not -extensions v3_req used in the certificate creation?
Because it has to be able to sign itself?
I just checked a couple RFCs. If this is a root CA cert, of course it is self-signed. By definition.
But a self-signed server cert is not a CA root cert....
On Jan 8, 2013, at 4:27 PM, Robert Moskowitz wrote:
On 01/08/2013 05:07 PM, Gordon Messmer wrote:
On 01/08/2013 11:49 AM, Robert Moskowitz wrote:
Why was this chosen? Why is not -extensions v3_req used in the certificate creation?
Because it has to be able to sign itself?
I just checked a couple RFCs. If this is a root CA cert, of course it is self-signed. By definition.
But a self-signed server cert is not a CA root cert....
---- it is a CA root certificate if I say it is.
Craig
On 01/08/2013 06:31 PM, Craig White wrote:
On Jan 8, 2013, at 4:27 PM, Robert Moskowitz wrote:
On 01/08/2013 05:07 PM, Gordon Messmer wrote:
On 01/08/2013 11:49 AM, Robert Moskowitz wrote:
Why was this chosen? Why is not -extensions v3_req used in the certificate creation?
Because it has to be able to sign itself?
I just checked a couple RFCs. If this is a root CA cert, of course it is self-signed. By definition.
But a self-signed server cert is not a CA root cert....
it is a CA root certificate if I say it is.
Fine. Be that way. But then you still need a server cert to use in the SSL default virtual host.
Root certs are for signing other certs, not for using directly in applications.
On 01/08/2013 06:31 PM, Craig White wrote:
On Jan 8, 2013, at 4:27 PM, Robert Moskowitz wrote:
On 01/08/2013 05:07 PM, Gordon Messmer wrote:
On 01/08/2013 11:49 AM, Robert Moskowitz wrote:
Why was this chosen? Why is not -extensions v3_req used in the certificate creation?
Because it has to be able to sign itself?
I just checked a couple RFCs. If this is a root CA cert, of course it is self-signed. By definition.
But a self-signed server cert is not a CA root cert....
it is a CA root certificate if I say it is.
On further review there is a /etc/pki/CA/certs (and .../CA/private) for the placement of CA certs. /etc/pki/tls is for end-entity certs.
On 01/08/2013 03:27 PM, Robert Moskowitz wrote:
I just checked a couple RFCs. If this is a root CA cert, of course it is self-signed. By definition.
Yes.
But a self-signed server cert is not a CA root cert....
Yes, it is. A certificate is a root cert unless some other certificate has signed it. x509 creates a chain of trust. The root of that chain is the certificate which has no other certificate's signature on it. A self-signed cert is its own root, and all root certificates are self-signed.
On 01/08/2013 06:38 PM, Gordon Messmer wrote:
On 01/08/2013 03:27 PM, Robert Moskowitz wrote:
I just checked a couple RFCs. If this is a root CA cert, of course it is self-signed. By definition.
Yes.
But a self-signed server cert is not a CA root cert....
Yes, it is. A certificate is a root cert unless some other certificate has signed it. x509 creates a chain of trust. The root of that chain is the certificate which has no other certificate's signature on it. A self-signed cert is its own root, and all root certificates are self-signed.
CA:TRUE means it is a signing cert. In RFC 5280, app C.2 end-entity cert:
(g) the certificate is an end entity certificate, as the basic constraints extension is not present;
On 01/08/2013 04:42 PM, Robert Moskowitz wrote:
CA:TRUE means it is a signing cert. In RFC 5280, app C.2 end-entity cert: (g) the certificate is an end entity certificate, as the basic constraints extension is not present;
OK. If you want to suggest to Red Hat use "-extensions v3_req", you'll probably need to do so as a paying customer, in bugzilla. "why" probably isn't a question for this list. CentOS simply rebuilds the source that Red Hat provides.
On 01/08/2013 08:15 PM, Gordon Messmer wrote:
On 01/08/2013 04:42 PM, Robert Moskowitz wrote:
CA:TRUE means it is a signing cert. In RFC 5280, app C.2 end-entity cert: (g) the certificate is an end entity certificate, as the basic constraints extension is not present;
OK. If you want to suggest to Red Hat use "-extensions v3_req", you'll probably need to do so as a paying customer, in bugzilla. "why" probably isn't a question for this list. CentOS simply rebuilds the source that Red Hat provides.
I know that I would have to take this to bugzilla if my reading was correct. And on further review, I am holding more that way. So I will put in the bug report even without being a paying customer. Just my cred on working on PKIX back a decade ago and being the architect of the Bridge CA model for the US Federal and BioPharma PKIs...
On 01/08/2013 05:30 PM, Robert Moskowitz wrote:
I know that I would have to take this to bugzilla if my reading was correct. And on further review, I am holding more that way. So I will put in the bug report even without being a paying customer. Just my cred on working on PKIX back a decade ago and being the architect of the Bridge CA model for the US Federal and BioPharma PKIs...
"cred" is frequently unrecognized by developers, so my advice would be to skip that part. Stick to a description of the problem as you see it, and what solutions are available. For example:
---
When mod_ssl is installed (and possibly other openssl packages) it creates a new certificate for localhost using the following command: /usr/bin/openssl req -new -key /etc/pki/tls/private/localhost.key \ -x509 -days 365 -set_serial $RANDOM \ -out /etc/pki/tls/certs/localhost.crt
In the distributed openssl configuration, this will create an x509 cert which uses the extensions included in the v3_ca section of the openssl.cfg file.
If any user connects to a service using such an automatically generated certificate, and accepts installation of the self-signed certificate (the default acceptance option in Firefox), it will be stored in their trusted CA list, as its constraints specify CA:True.
This creates unnecessary risk. Anyone with access to such a certificate can later sign a certificate for any hostname, and users who have accepted the self-signed cert will see no warnings. If the command is modified to specify the v3_req extensions rather than the default, the resulting certificate will be equally usable, without creating undue risk for users who accept the certificate. /usr/bin/openssl req -new -key /etc/pki/tls/private/localhost.key \ -x509 -days 365 -set_serial $RANDOM \ -extensions v3_req \ -out /etc/pki/tls/certs/localhost.crt
----
However, I have no idea how seriously anyone will take the issue unless there's a broad base of users who request such a change. The situation can be made slightly better by this change, but making it doesn't make self-signed certificates less common. As long as self-signed certificates are common, users will get into the habit of permanently accepting untrusted certs. If they do that, and the cert specifies that it is a CA, then they've installed a new CA.
These certs are just a small part of a much larger and more serious design problem with SSL. User agents (especially Firefox) don't really make clear that a new cert is a CA, rather than a certificate with more limited purpose. Users can't really be expected to learn the difference, either.
I really hope that the whole trust chain aspect of SSL is thrown away someday soon, replaced by some better model. Convergence.io is one I really like.
-
Craig White -
Gordon Messmer -
Robert Moskowitz