On 12/20/2012 03:44 AM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Robert Moskowitz
Sent: Wednesday, 19 December, 2012 22:24
... I am trying better to understand ...
creating a mailserver (postfix) cert.
I am looking at a couple templets. The one at postfix.org creates a
'unsigned public key certificate':
openssl req -new -nodes -keyout foo-key.pem -out foo-req.pem -days 365
There is no such thing as an 'unsigned public key certificate'.
Wherever you saw that should be regarded with suspicion.
I was active in PKIX early on, worked on the US Federal PKI , and author
of the Bridge CA model it (and BioPharma) use. I am quite aware of this.
The site for this template is:
http://www.postfix.org/TLS_README.html :)
On further reading of their howto, they are creating a 'CA' cert, a CSR,
then signing that. They really don't have a self signed example.
Certs are signed, that's part of what makes them certs.*
That command creates a cert signing request, aka cert request,
aka CSR, but -days n and -nodes are useless for that command,
so as a template this should be regarded with suspicion.
* Related: if there or anywhere you see a claim that a CA "signs"
a CSR, or the user/entity/server/client/etc sends a CSR to a CA
"to be signed" or words to that effect, that is quite wrong
and indicates that the author either doesn't know what they're
talking about or does not want to explain it correctly.
A cert is signed, and usually a cert contains information >from<
a CSR and it is vital it does, but the signed data (TBS) in
the cert is NOT a copy of the CSR nor of the TBS in the CSR.
It is a different structure, which OpenSSL calls X509_CINF.
The name 'certificate signing request' may contribute to this
problem, because it calls attention to only one part of what the
CA does. Maybe it should have been named certificate >issuance<
request or certificate >creation< request or somesuch. It wasn't.
I kind of remember some of these naming debates. Was back in the '90s,
so memory is foggy.
A tutorial I am working with creates a 'self-signed certificate':
openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048 -nodes
-keyout smtpd.key -keyform PEM -days 365 -x509
I have figured out that the two -xxxform PEM parameters are only
selecting the default value (and probably has always been the default
for openssl) so can be dropped. The challenge is the -x509
parameter.
It does not seem to be the default for req, and yet the -days
nnn option
seems to be tied to it. The man page says:
-x509
this option outputs a self signed certificate instead of a
certificate request. This is typically used to
generate a test
certificate or a self signed root CA. The
extensions added
to the
certificate (if any) are specified in the
configuration file.
Unless specified using the set_serial option 0
will be used
for the
serial number.
-days n
when the -x509 option is being used this
specifies the number of
days to certify the certificate for. The default
is 30 days.
So is -x509 the default? If not, what is the default, and for the
default what does -days nnn do?
-x509 is not the default. As the manpage says, -x509 outputs
a self-signed cert >instead of< a CSR. The default if -x509
is not specified is to output a CSR. (If you use -new or -newkey
without -x509 it *creates* a CSR and outputs that new CSR, as
you have here. 'req' can also process an existing CSR.)
This was not clear from the man age on req.
The req command primarily creates and processes certificate requests in
PKCS#10 format. It can additionally create self signed certificates for
use as root CAs for example.
Now that I read the -new and -newkey options again, I begin to see this.
I ASSuME there is a nice wiki on all of this ;)'
If -x509 is used and it outputs a cert, a cert has a validity
period, which can be set with -days n and defaults to 30 days.
Got that. Lots of debates about validity fields back in the days.
If -x509 is not used and it outputs a CSR, a CSR does not have
a validity period, and -days n is useless. See above.
Yes, it is the CA signing CSR that sets the validity date based on its
policy. Though there were debates that the requester SHOULD be able to
specify its requested validity date that the CA may override. For
example the CSR MAY have a date earlier than the CA's policy, but not
beyond.
Because openssl utilities generally parse all arguments before
starting to process them, you often including here do NOT get
an error message for specifying unnecessary/unused options.
Warnings would be nice.
Thank you for your response.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
