On 12/20/2012 08:08 AM, /dev/rob0 wrote:
BTW Reply-To: is set, and the offlist Cc: is not necessary.
On Wed, Dec 19, 2012 at 07:40:10PM -0500, Robert Moskowitz wrote:
On 12/19/2012 06:31 PM, /dev/rob0 wrote:
On Wed, Dec 19, 2012 at 02:38:52PM -0500, Robert Moskowitz wrote:
I am looking at a number of tutorials for setup.
This is a formula for failure. :) Stick to the documentation.
http://www.postfix.org/documentation.html
I looked there again, and did not see an example for creating a
By "there" I presume you mean the TLS_README, specifically the
"Getting started, quick and dirty" section at the end.
That is the only place in the documentation where I have found openssl
command examples. Are there other place(s) that I have missed?
self-signed cert. Oh, 'unsigned' is what the docs says. What do you
mean 'unsigned'. No such thing in PKIX; the term is self-signed. No
wonder I missed it the first time through the docs:
openssl req -new -nodes -keyout foo-key.pem -out foo-req.pem -days 365
This is a CSR, not a certificate. You go on to sign it with the CA.
You and Viktor are certainly much more knowledgeable about x509 than
I am, but I think that's what is meant by "unsigned public key
certificate". I've been calling it "CSR", for "certificate signing
request."
Yes, you SHOULD call it what it is in PKIX: "certficate signing
request". Of course even that is confusing to many, but that is what
the X.509 and PKIX community chose. It is NOT an "unsigned public key
certificate". It is a request for a certificate.
Now I actually know a LOT about X.509, having worked on PKIX
in IETF. But I am theory, not practice. I want control over
CN content and the tutorial with the later shows what I want.
We don't know what you want. What is this certificate to be
used for? Do you want a self-signed certificate, or to run
your own CA, or to submit your CSR to an external CA?
Valid point that I did not communicate. I have run CAs and can't
see why for this usage.
It might be handy if in the future you wanted to do TLS-based
authentication. See the "Server access control" section. You would
want to maintain a CA for this purpose. If you already have a CA for
another purpose, you can just as well sign your certificate with
that.
I don't see this. Self-signed certs have ALWAYS worked for PKIX
applications. The uset gets a warning and has to accept the cert the
first time. But even in your example, the user would have to install
your CA cert. Are you saying (and I can't see this in the docs) that
you need a separate cert for TLS-based authentication? Why?
Can't see why to pay for a cert either; but you would not know that.
Those who want a commercially-signed certificate for a mail server
are typically also using it for IMAP, and they want something that
their users' MUAs will happily accept without a hiccup. But there, I
would consider just giving them a detailed howto page on importing
your CA cert.
I have been in LOTS of CA policy debates, so I let a bit of my opinions
of those old debates, where I lost to the lawyers (I had to become an
associate member of the BAR to even participate :( ) bleed into my
response. The whole third-party attestation model is fraught which bad
assumptions. Note that I am the author of the HIP protocol in the IETF
that uses raw public keys and have successfully pushed to get this
general model adopted in CORE. So I am biased ;)
Other than that, for SMTP, there is little to no need for this.
You're unlikely to do any certificate checking on the server side,
nor offering a certificate on the client side.
