generating the TLS cert

[Robert Moskowitz]

I am looking at a number of tutorials for setup. I have found two
different commands and looking for guidance:

genkey --days 3650 mail.example.com

or

openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048 -nodes
-keyout smtpd.key -keyform PEM -days 365 -x509

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.

[/dev/rob0]

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 have found two different commands and looking for guidance:
>
> genkey --days 3650 mail.example.com

I don't know what this is, but it probably generates a 10-year
certificate? There is no "genkey" command on my system with OpenSSL
0.9.8x, and "genkey" is not a valid subcommand of openssl(1).

> or
>
> openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048
> -nodes -keyout smtpd.key -keyform PEM -days 365 -x509

Each of the options you have listed in your command are documented in
the OpenSSL req(1) manual.

> 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?
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[Reindl Harald]

Am 20.12.2012 00:31, schrieb /dev/rob0:

> 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?

there is no difference between self-signed and submit to external CA
the script below makes crt/csr/pem for any usecase

[root@buildserver:~]$ cat /buildserver/ssl-cert/generate-cert.sh
#!/usr/bin/bash
WORKING_DIR="/buildserver/ssl-cert"
OUT_DIR="$WORKING_DIR/$1"
mkdir $OUT_DIR 2> /dev/null
chmod 700 $OUT_DIR
if [ "$1" == "" ]; then
echo "Wie soll ich bitte Dateien ohne Servernamen benennen?"
echo ""
exit
fi
rm -f $OUT_DIR/$1.key
rm -f $OUT_DIR/$1.csr
rm -f $OUT_DIR/$1.crt
rm -f $OUT_DIR/$1.pem
sed "s/my_common_name/$1/g" $WORKING_DIR/openssl.conf.template > $WORKING_DIR/openssl.conf
openssl genrsa -out $OUT_DIR/$1.key 2048
openssl req -config $WORKING_DIR/openssl.conf -new -key $OUT_DIR/$1.key -out $OUT_DIR/$1.csr
openssl x509 -req -days 3650 -in $OUT_DIR/$1.csr -signkey $OUT_DIR/$1.key -out $OUT_DIR/$1.crt
cat $OUT_DIR/$1.crt $OUT_DIR/$1.key > $OUT_DIR/$1.pem
echo ""
echo "Zertifikate wurden unter '$OUT_DIR/' erstellt."
echo $OUT_DIR/$1.key
echo $OUT_DIR/$1.csr
echo $OUT_DIR/$1.crt
echo $OUT_DIR/$1.pem
echo ""

chmod 600 $OUT_DIR/*
ls -l -h --color=tty -X --group-directories-first --time-style=long-iso $OUT_DIR/
echo ""
rm -f $WORKING_DIR/openssl.conf


[root@buildserver:~]$ cat /buildserver/ssl-cert/openssl.conf.template
[ req ]
prompt = yes
default_bits = 1024
distinguished_name = req_DN
string_mask = nombstr
[ req_DN ]
countryName = "1. Landeskennung "
countryName_default = "AT"
countryName_min = 2
countryName_max = 2
stateOrProvinceName = "2. Bundesland "
stateOrProvinceName_default = "Vienna"
localityName = "3. Stadt "
localityName_default = "Vienna"
0.organizationName = "4. Firmenname "
0.organizationName_default = "the lounge interactive design gmbh"
organizationalUnitName = "5. Abteilung "
organizationalUnitName_default = "Administration"
commonName = "6. Server-Name "
commonName_max = 64
commonName_default = "my_common_name"
emailAddress = "7. Mail-Adresse "
emailAddress_max = 40
emailAddress_default = "hostm...@thelounge.net"

[Robert Moskowitz]

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
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

>
>> I have found two different commands and looking for guidance:
>>
>> genkey --days 3650 mail.example.com
> I don't know what this is, but it probably generates a 10-year
> certificate? There is no "genkey" command on my system with OpenSSL
> 0.9.8x, and "genkey" is not a valid subcommand of openssl(1).

Yep, a 10 year cert; that is clear, but what else is in the cert. Well
you also can't find this command! Perhaps I have not looked closely
enough at the tutorial to see what other cruft they installed. But
probably will not push with this approach.

>
>> or
>>
>> openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048
>> -nodes -keyout smtpd.key -keyform PEM -days 365 -x509
> Each of the options you have listed in your command are documented in
> the OpenSSL req(1) manual.

Will look again at the man on this.

>
>> 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. Can't see why to pay for a cert either; but you would
not know that. Both examples are suppose to create self-signed certs,
but I did not say that is what I wanted. My error; doing too many things
at one time.

All I want for this server is a self-signed cert. I will settle for
SHA-1, as I can't count on SHA-256 support and the risk is low for now.
RSA 2048 will do; if I need larger, I will gen up an new cert next year.
ECDSA would be fun, but support is thin. I do want a full CN that the
second example prompts for. It is just that I missed the 'nice' 'here is
how to create a self-signed cert' over at the postfix.org site. Now I
see it. Yet another example to compare.

[Robert Moskowitz]

On 12/19/2012 06:40 PM, Reindl Harald wrote:
>
> Am 20.12.2012 00:31, schrieb /dev/rob0:
>

>> 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?

> there is no difference between self-signed and submit to external CA

True. Just the user experience thing and server maintainer costs. This
is not the place to debate the whole X.509 world; I live it as part of
my day job.

> the script below makes crt/csr/pem for any usecase

Thank you Harald.

[Robert Moskowitz]

On 12/19/2012 06:40 PM, Reindl Harald wrote:
>
> Am 20.12.2012 00:31, schrieb /dev/rob0:
>
>> 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?
> there is no difference between self-signed and submit to external CA

> the script below makes crt/csr/pem for any usecase

Got a better feel for your script now and the two decent examples of
openssl req

But I will probably have to go subscribe to the openssl list and ask
there about the -x509 option. from the man page, this does not seem to
be the default, and you need it to get a self-signed cert. And the -days
only applies when -x509 is asserted.

More study is needed.

[Viktor Dukhovni]

On Wed, Dec 19, 2012 at 02:38:52PM -0500, Robert Moskowitz wrote:

> I am looking at a number of tutorials for setup. I have found two

> different commands and looking for guidance:
>
> genkey --days 3650 mail.example.com
>

> or
>
> openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048
> -nodes -keyout smtpd.key -keyform PEM -days 365 -x509

http://archives.neohapsis.com/archives/postfix/2012-11/0476.html

$ tmp=$(mktemp smtpd.pem.XXXXXX)
$ openssl req -new -x509 -newkey rsa:1280 -nodes -keyout /dev/stdout \
-days $((356 * 10)) -subj "/CN=$(uname -n)" >> "$tmp"
$ mv "$tmp" smtpd.pem

Everything other than "CN" in the subject DN is a waste of bits.
The "mktemp" command generates a file with sensible permissions
for key material, otherwise you need to mess with umasks, since
OpenSSL makes no effort to prevent files with keys being world
readable.

--
Viktor.

[John Hinton]

On 12/19/2012 6:40 PM, Reindl Harald wrote:
>
> Am 20.12.2012 00:31, schrieb /dev/rob0:
>
>> 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?
> there is no difference between self-signed and submit to external CA
> the script below makes crt/csr/pem for any usecase
>

I have heard some reports that browsers such as Chrome and MSIE balk at
1024 bit certs and that one should use 2048. I wonder if this is now a
good idea when generating mailserver certs as well? Try to be more
future proof? Or am I confused and thinking 512 and 1024? Either way,
this is a good decision to think about so your users won't have to grab
a new cert if you need to change it. The uninformed can get spooked by
these things. I personally believe signed certs for mailservers should
be free.

--
John Hinton
877-777-1407 ext 502
http://www.ew3d.com
Comprehensive Online Solutions

[Jerry]

On Wed, 19 Dec 2012 23:58:49 -0500
John Hinton articulated:

> I have heard some reports that browsers such as Chrome and MSIE balk
> at 1024 bit certs and that one should use 2048. I wonder if this is
> now a good idea when generating mailserver certs as well? Try to be
> more future proof? Or am I confused and thinking 512 and 1024? Either
> way, this is a good decision to think about so your users won't have
> to grab a new cert if you need to change it. The uninformed can get
> spooked by these things. I personally believe signed certs for
> mailservers should be free.

I have not see an example of MSIE balking at 1024 bit certs. Not sure
about the 512 version though and I have no working knowledge of Chrome.

--
Jerry ✌
postfi...@seibercom.net
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

[Robert Moskowitz]

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 asked some questions over on the OPenSSL list and better understand
what the postfix documentation does NOT help with.

The example on http://www.postfix.org/TLS_README.html is more than most
users need, as Harald shared. It needs a simple example of a self-signed
cert by inclusion of the -x509 option. And if you read the man page for
req, -days option ONLY applies to the -x509 option. If you are only
creating a CSR as in this example, the days is set by the signing CA,
and I don't see a -days option in the CA signing step. Now back in the
PKIX debates of old there were MAYs for the CSR including a validity
date, but only shorter than the CA's policy.

So adding an example like:

openssl req -new -nodes -keyout foo-key.cert -out foo-cert.cert -x509
-days 365

Would be helpful.

Words about -newkey rsa:2048 would be helpful. THough right now 2048 is
the default. See my upcoming post on Harald's 1024 key size.

>
>> I have found two different commands and looking for guidance:
>>
>> genkey --days 3650 mail.example.com

> I don't know what this is, but it probably generates a 10-year
> certificate? There is no "genkey" command on my system with OpenSSL
> 0.9.8x, and "genkey" is not a valid subcommand of openssl(1).
>

>> or
>>
>> openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048
>> -nodes -keyout smtpd.key -keyform PEM -days 365 -x509

> Each of the options you have listed in your command are documented in
> the OpenSSL req(1) manual.
>

>> 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.

[Robert Moskowitz]

On 12/19/2012 11:58 PM, John Hinton wrote:
> On 12/19/2012 6:40 PM, Reindl Harald wrote:
>> [root@buildserver:~]$ cat /buildserver/ssl-cert/openssl.conf.template
>> [ req ]
>> prompt = yes
>> default_bits = 1024
>>

> I have heard some reports that browsers such as Chrome and MSIE balk
> at 1024 bit certs and that one should use 2048. I wonder if this is
> now a good idea when generating mailserver certs as well? Try to be
> more future proof? Or am I confused and thinking 512 and 1024? Either
> way, this is a good decision to think about so your users won't have
> to grab a new cert if you need to change it. The uninformed can get
> spooked by these things. I personally believe signed certs for
> mailservers should be free

Check out the NSA/NIST keysize recommendations:
http://www.nsa.gov/business/programs/elliptic_curve.shtml

1024 is for a 80 bit symmetric strength. This has be 'deprecated' for
112 bit minimum which requires an rsa:2048 or ecdsa:224. To get full
aes 128 strength you need rsa:3072 or ecdsa:256. This is the case for
ecdsa.

[/dev/rob0]

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.

> 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."

> >>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.

> 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.

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.

[Robert Moskowitz]

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 ;)

[Viktor Dukhovni]

On Thu, Dec 20, 2012 at 08:40:42AM -0500, Robert Moskowitz wrote:

> That is the only place in the documentation where I have found
> openssl command examples. Are there other place(s) that I have
> missed?

What would you like to see in the documentation? Instructions for
creating a self-signed server certificate without a parent issuing
CA? This could be added I guess, but the Postfix TLS_README is not
intended or going to be a comprehensive guide to OpenSSL and X.509.

People who want ECDSA certs and perhaps TLS 1.2 SHA256 message
digests, ... will sadly have to learn about these elsewhere.
For most users, the simplest recipe will suffice.

People who want a more compact recipe for a self-signed cert on
a single SMTP server can use my "one-liner" (for machines whose
hostname is an FQDN):

$ tmp=$(mktemp smtpd.pem.XXXXXX) &&
openssl req -new \
-newkey rsa:1280 -keyout /dev/stdout \
-x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
mv "$tmp" smtpd.pem

> I have been in LOTS of CA policy debates, ...

This thread is veering off course. What is the question at this
point?

--
Viktor.

[Viktor Dukhovni]

On Thu, Dec 20, 2012 at 02:15:35PM +0000, Viktor Dukhovni wrote:

> People who want a more compact recipe for a self-signed cert on
> a single SMTP server can use my "one-liner" (for machines whose
> hostname is an FQDN):
>
> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> openssl req -new \
> -newkey rsa:1280 -keyout /dev/stdout \
> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> mv "$tmp" smtpd.pem

With the "-nodes" option in most cases:

$ tmp=$(mktemp smtpd.pem.XXXXXX) &&
openssl req -new \

-newkey rsa:1280 -nodes -keyout /dev/stdout \

-x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
mv "$tmp" smtpd.pem

--
Viktor.

[Wietse Venema]

Viktor Dukhovni:

> > People who want a more compact recipe for a self-signed cert on
> > a single SMTP server can use my "one-liner" (for machines whose
> > hostname is an FQDN):

...

> With the "-nodes" option in most cases:
>
> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> openssl req -new \
> -newkey rsa:1280 -nodes -keyout /dev/stdout \
> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> mv "$tmp" smtpd.pem

And with accompanying configuration:

/etc/postfix/main.cf:
smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_key_file = /etc/postfix/smtpd.pem
smtpd_tls_security_level = may

which leaves smtpd_tls_CAfile at its default empty value.

Correct? I'm combining fragments from email postings with some
additional narrative, so that the result becomes usable for a
tutorial section in TLS_README.

Wietse

[Viktor Dukhovni]

Yes and one can even leave smtpd_tls_key_file unset, since it
defaults to $smtpd_tls_cert_file.

New text would be something like:

The above recipe creates a signing CA which enables the signing of
certificates for multiple servers and/or the issuing of client
certificates issued by your own private CA. If all you need is is
a self-signed X.509 certificate for a single server (usable for
both SMTP and IMAP) then a much shorter recipe is:

<blockquote>
<pre>
# <b>bits=1280</b>
# <b>days=$((365 * 10))</b>
# <b>fqdn=$(uname -n)</b>
# <b>tmp=$(mktemp smtpd.pem.XXXXXX) &amp;&amp;
openssl req -new \
-newkey rsa:$bits -nodes -keyout /dev/stdout \
-x509 -days "$days" -subj "/CN=$fqdn" >> "$tmp" &amp;&amp;
mv "$tmp" smtpd.pem</b>
</pre>
</blockquote>

We could follow the herd and recommend 2048 bits, since SMTP servers
rarely do enough RSA-ops for RSA performance to be a bottleneck.
On the other-hand, for people wielding self-signed certs almost
certainly 1024 is plenty strong at 2^80, and 1280 raises this a
notch to 2^89 with a much lower performance penaly than RSA 2048
(whose GNFS factoring cost is ~2^112).

--
Viktor.

[John Hinton]

On 12/20/2012 10:30 AM, Viktor Dukhovni wrote:
> We could follow the herd and recommend 2048 bits, since SMTP servers
> rarely do enough RSA-ops for RSA performance to be a bottleneck. On
> the other-hand, for people wielding self-signed certs almost certainly
> 1024 is plenty strong at 2^80, and 1280 raises this a notch to 2^89
> with a much lower performance penaly than RSA 2048 (whose GNFS
> factoring cost is ~2^112).

I did go back to look and in fact replacing a 1024 cert with a 2048 cert
cured 'some' browser issues with self signed certs. I have not seen this
make it to any email client yet, but expect it will. I agree that this
is a resource waste in most situations, likely all where a self signed
cert is used. My point is simply trying to get the future right, so I
don't wake up to a morning of customer complaints when the next update
to 'no insight' launches. I can't help but wonder if some of these
products making it harder to use self signed certs are produced by
companies looking at getting into the CA business? More than enough said.

For us, we use self signed certs with our hosting clients for one main
reason. We set DNS for mailsystems on their domain name. They can then
use something like mail.mydomain.com as their mailserver. We can move
them to another server here and not have any affect on their email
settings (other than accepting the new cert). We are mainly interested
in passing login information using encryption.

[Robert Moskowitz]

On 12/20/2012 09:32 AM, Viktor Dukhovni wrote:
> On Thu, Dec 20, 2012 at 02:15:35PM +0000, Viktor Dukhovni wrote:
>

>> People who want a more compact recipe for a self-signed cert on
>> a single SMTP server can use my "one-liner" (for machines whose
>> hostname is an FQDN):
>>

>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>> openssl req -new \

>> -newkey rsa:1280 -keyout /dev/stdout \

>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>> mv "$tmp" smtpd.pem
> With the "-nodes" option in most cases:
>
> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> openssl req -new \
> -newkey rsa:1280 -nodes -keyout /dev/stdout \
> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> mv "$tmp" smtpd.pem

Where is the cert going in this example? Are you putting both the cert
and the private key in the same file?

I would tend to at least include emailAddress. The rest SHOULD be known
to the mail users. Though if the cert is used between MTAs, then you
get that countryName gets important. But then it is no longer a
'simple' cert and go read the openssl docs as I have been doing recently :)

By having rsa:1280, a reasonable reader would get how to control their
keysize.

[Robert Moskowitz]

On 12/20/2012 10:02 AM, Wietse Venema wrote:
> Viktor Dukhovni:

>>> People who want a more compact recipe for a self-signed cert on
>>> a single SMTP server can use my "one-liner" (for machines whose
>>> hostname is an FQDN):

> ...

>> With the "-nodes" option in most cases:
>>
>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>> openssl req -new \
>> -newkey rsa:1280 -nodes -keyout /dev/stdout \
>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>> mv "$tmp" smtpd.pem

> And with accompanying configuration:
>
> /etc/postfix/main.cf:
> smtpd_tls_cert_file = /etc/postfix/smtpd.pem
> smtpd_tls_key_file = /etc/postfix/smtpd.pem
> smtpd_tls_security_level = may

Oh, I see. Yes you ARE putting both the cert and the key in one file.
Interesting.

>
> which leaves smtpd_tls_CAfile at its default empty value.
>
> Correct? I'm combining fragments from email postings with some
> additional narrative, so that the result becomes usable for a
> tutorial section in TLS_README.

I think so. I don't know the main.cf format and I am trying to put all
of my changes in via postconf -e commands, So I can understand each item
in the file. I think. Therefore I am, I think. (from the Moody Blues
'Days of Future Past')

[Wietse Venema]

Robert Moskowitz:

> > With the "-nodes" option in most cases:
> >
> > $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> > openssl req -new \
> > -newkey rsa:1280 -nodes -keyout /dev/stdout \
> > -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> > mv "$tmp" smtpd.pem
>

> Where is the cert going in this example? Are you putting both the cert
> and the private key in the same file?

Yes. Postfix by default uses the same file for the private key and
the public key certificate.

> I would tend to at least include emailAddress. The rest SHOULD be known

No. This is a server certificate. Servers have no email address.
Second, this is a self-signed certificate, meaning no assurance
that the information is trusworthy, so no point loading it up.

Wietse

[Robert Moskowitz]

On 12/20/2012 10:30 AM, Viktor Dukhovni wrote:

> On Thu, Dec 20, 2012 at 10:02:19AM -0500, Wietse Venema wrote:
>
>> Viktor Dukhovni:
>>>> People who want a more compact recipe for a self-signed cert on
>>>> a single SMTP server can use my "one-liner" (for machines whose
>>>> hostname is an FQDN):
>> ...

>>> With the "-nodes" option in most cases:
>>>
>>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>>> openssl req -new \
>>> -newkey rsa:1280 -nodes -keyout /dev/stdout \
>>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>>> mv "$tmp" smtpd.pem

>> And with accompanying configuration:
>>
>> /etc/postfix/main.cf:
>> smtpd_tls_cert_file = /etc/postfix/smtpd.pem
>> smtpd_tls_key_file = /etc/postfix/smtpd.pem
>> smtpd_tls_security_level = may
>>

>> which leaves smtpd_tls_CAfile at its default empty value.
>>
>> Correct? I'm combining fragments from email postings with some
>> additional narrative, so that the result becomes usable for a
>> tutorial section in TLS_README.

> Yes and one can even leave smtpd_tls_key_file unset, since it
> defaults to $smtpd_tls_cert_file.

This may be one of those cases where including a command the is
essentially the default avoids confusion and questions like I would ask.

> New text would be something like:
>
> The above recipe creates a signing CA which enables the signing of
> certificates for multiple servers and/or the issuing of client
> certificates issued by your own private CA. If all you need is is
> a self-signed X.509 certificate for a single server (usable for
> both SMTP and IMAP) then a much shorter recipe is:
>
> <blockquote>
> <pre>
> # <b>bits=1280</b>
> # <b>days=$((365 * 10))</b>
> # <b>fqdn=$(uname -n)</b>
> # <b>tmp=$(mktemp smtpd.pem.XXXXXX) &amp;&amp;

> openssl req -new \

> -newkey rsa:$bits -nodes -keyout /dev/stdout \
> -x509 -days "$days" -subj "/CN=$fqdn" >> "$tmp" &amp;&amp;
> mv "$tmp" smtpd.pem</b>
> </pre>
> </blockquote>
>

> We could follow the herd and recommend 2048 bits, since SMTP servers
> rarely do enough RSA-ops for RSA performance to be a bottleneck.
> On the other-hand, for people wielding self-signed certs almost
> certainly 1024 is plenty strong at 2^80, and 1280 raises this a
> notch to 2^89 with a much lower performance penaly than RSA 2048
> (whose GNFS factoring cost is ~2^112).

Or just words that bits can be set to the strength/performance trade-off
desired.

I will just go with 2048, as I am too vested in this whole debate and
one of my colleagues will find my cert and ask me why it is x rather
than y. As it is, I will get some grief on SHA1!

[Robert Moskowitz]

Oh, and thank you for answering my questions, helping me work through
understanding this small portion of the problem space, and adding the
lessons I am taking away from the exchanges to the documentation.

On 12/20/2012 10:30 AM, Viktor Dukhovni wrote:
> On Thu, Dec 20, 2012 at 10:02:19AM -0500, Wietse Venema wrote:
>
>> Viktor Dukhovni:
>>>> People who want a more compact recipe for a self-signed cert on
>>>> a single SMTP server can use my "one-liner" (for machines whose
>>>> hostname is an FQDN):
>> ...
>>> With the "-nodes" option in most cases:
>>>
>>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>>> openssl req -new \
>>> -newkey rsa:1280 -nodes -keyout /dev/stdout \
>>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>>> mv "$tmp" smtpd.pem
>> And with accompanying configuration:
>>
>> /etc/postfix/main.cf:
>> smtpd_tls_cert_file = /etc/postfix/smtpd.pem
>> smtpd_tls_key_file = /etc/postfix/smtpd.pem
>> smtpd_tls_security_level = may
>>
>> which leaves smtpd_tls_CAfile at its default empty value.
>>
>> Correct? I'm combining fragments from email postings with some
>> additional narrative, so that the result becomes usable for a
>> tutorial section in TLS_README.
> Yes and one can even leave smtpd_tls_key_file unset, since it
> defaults to $smtpd_tls_cert_file.
>

[Robert Moskowitz]

On 12/20/2012 08:29 PM, Wietse Venema wrote:
> Robert Moskowitz:

>>> With the "-nodes" option in most cases:
>>>
>>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>>> openssl req -new \
>>> -newkey rsa:1280 -nodes -keyout /dev/stdout \
>>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>>> mv "$tmp" smtpd.pem

>> Where is the cert going in this example? Are you putting both the cert
>> and the private key in the same file?
> Yes. Postfix by default uses the same file for the private key and
> the public key certificate.
>
>> I would tend to at least include emailAddress. The rest SHOULD be known
> No. This is a server certificate. Servers have no email address.

We can debate this, but little gained. I am OK with this as a basic
template.

> Second, this is a self-signed certificate, meaning no assurance
> that the information is trusworthy, so no point loading it up.

:)

Again, thank you both for your efforts.

[Robert Moskowitz]

On 12/20/2012 08:29 PM, Wietse Venema wrote:
> Robert Moskowitz:
>>> With the "-nodes" option in most cases:
>>>
>>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>>> openssl req -new \
>>> -newkey rsa:1280 -nodes -keyout /dev/stdout \
>>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>>> mv "$tmp" smtpd.pem
>> Where is the cert going in this example? Are you putting both the cert
>> and the private key in the same file?
> Yes. Postfix by default uses the same file for the private key and
> the public key certificate.
>
>> I would tend to at least include emailAddress. The rest SHOULD be known
> No. This is a server certificate. Servers have no email address.

> Second, this is a self-signed certificate, meaning no assurance
> that the information is trusworthy, so no point loading it up.

Past my bedtime, but...

I was thinking about this, and what assurance does your CA provide for
the names in the certs it signs? Where are the policies? I have helped
set up large commercial CAs with all of the policy cruft with the
lawyers checking over everything. Naming assurances are all about what
you want to trust.

Well, as I said, past my bedtime and I REALLY should not be thinking
about this stuff. It gives me nightmares ;)

Made some headway this evening on the important stuff. Like the real
postfix conf and some time with postfixadmin.

[Wietse Venema]

Robert Moskowitz:

> I was thinking about this, and what assurance does your CA provide for
> the names in the certs it signs?

It provides assurance that the certificate was signed by your CA.
That is all. The rest is just a lot of wishful thinking that keeps
techno-parasites in business.

Wietse

[Jerry]

On Fri, 21 Dec 2012 07:03:29 -0500 (EST)
Wietse Venema articulated:

+1

--
Jerry ✌
postfi...@seibercom.net
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Henri Estienne

[Robert Moskowitz]

On 12/21/2012 07:29 AM, Jerry wrote:
> On Fri, 21 Dec 2012 07:03:29 -0500 (EST)
> Wietse Venema articulated:
>
>> Robert Moskowitz:
>>> I was thinking about this, and what assurance does your CA provide
>>> for the names in the certs it signs?
>> It provides assurance that the certificate was signed by your CA.
>> That is all. The rest is just a lot of wishful thinking that keeps
>> techno-parasites in business.
>>
>> Wietse
> +1
>

:)

Read RFC 4423 and the Internet Draft for 4423-bis. I walked away from
PKI long ago in terms of Identities. But PKI is the digital version of
a driver's license, or it tries to be...

Enough of this thread. It is too tempting for me to really rant, and
you people here don't deserve that!

[Robert Moskowitz]

An update on creating self-signed certs.

On 12/20/2012 09:32 AM, Viktor Dukhovni wrote:
> On Thu, Dec 20, 2012 at 02:15:35PM +0000, Viktor Dukhovni wrote:
>

>> People who want a more compact recipe for a self-signed cert on
>> a single SMTP server can use my "one-liner" (for machines whose
>> hostname is an FQDN):
>>

>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
>> openssl req -new \

>> -newkey rsa:1280 -keyout /dev/stdout \

>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
>> mv "$tmp" smtpd.pem
> With the "-nodes" option in most cases:
>
> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> openssl req -new \
> -newkey rsa:1280 -nodes -keyout /dev/stdout \
> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> mv "$tmp" smtpd.pem
>

I was noticing an error in /var/log/httpd/ssl_error_log about the cert
having basicConstraints: CA=TRUE

So I worked this out on the OpenSSL list had learned that the -x509
option graps the v3_ca section out of the openssl.cnf. By adding:

-extensions v3_req

I get CA=FALSE, though it adds KU which is not a problem.

So either supply your own config file (which I don't like as it is more
work to go wrong) or use the v3-req extention.

Just learning more about this onion. Layer by layer.

[Viktor Dukhovni]

On Thu, Jan 03, 2013 at 11:05:42AM -0500, Robert Moskowitz wrote:

> An update on creating self-signed certs.
>
> On 12/20/2012 09:32 AM, Viktor Dukhovni wrote:
> >On Thu, Dec 20, 2012 at 02:15:35PM +0000, Viktor Dukhovni wrote:
> >
> >>People who want a more compact recipe for a self-signed cert on
> >>a single SMTP server can use my "one-liner" (for machines whose
> >>hostname is an FQDN):
> >>
> >> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> >> openssl req -new \
> >> -newkey rsa:1280 -keyout /dev/stdout \
> >> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> >> mv "$tmp" smtpd.pem
> >With the "-nodes" option in most cases:
> >
> > $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
> > openssl req -new \
> > -newkey rsa:1280 -nodes -keyout /dev/stdout \
> > -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
> > mv "$tmp" smtpd.pem
> >
>
> I was noticing an error in /var/log/httpd/ssl_error_log about the
> cert having basicConstraints: CA=TRUE

If some HTTP server does not like self-signed SSL certs with CA=TRUE,
that's its own problem. Postfix will not force you to jump through
such pointless hoops.

--
Viktor.

[Robert Moskowitz]

It was a warning. More likely it would be the clients that would
object. Postfix may be happy with such a cert, but some other MTA or
client might not accept such a cert from Postfix.

One of the IETF mantras is "be conservative in what you send and liberal
in what you accept". So a client SHOULD accept this, but not MUST
accept it. A server MAY send it, but SHOULD avoid it.

So I was just sharing my experience in working with the cert and what
warnings I have been getting that are, based on the standards, correct
warnings.

But I think this is a pernicious problem as the localhost.crt created
during firstboot on my Centos 6.3 system has CA=TRUE. I need to look
into this more before I submit a bug report upstream to Redhat.

[Viktor Dukhovni]

On Fri, Jan 04, 2013 at 12:57:00AM -0500, Robert Moskowitz wrote:

> >>I was noticing an error in /var/log/httpd/ssl_error_log about the
> >>cert having basicConstraints: CA=TRUE
> >
> >If some HTTP server does not like self-signed SSL certs with CA=TRUE,
> >that's its own problem. Postfix will not force you to jump through
> >such pointless hoops.
> It was a warning. More likely it would be the clients that would
> object. Postfix may be happy with such a cert, but some other MTA
> or client might not accept such a cert from Postfix.
>
> One of the IETF mantras is "be conservative in what you send and
> liberal in what you accept". So a client SHOULD accept this, but
> not MUST accept it. A server MAY send it, but SHOULD avoid it.

There is nothing wrong with "CA:true" in a self-signed SSL certificate.
If, however, your default "openssl.cnf" adds "CA:true", and you'd rather
not have it present, the "one liner" can be updated slightly to:

# tmp=$(mktemp smptpd.pem.XXXXXX) &&
openssl req -new \
-newkey rsa:1280 -keyout "$tmp" -nodes \
-x509 -subj "/CN=$(uname -n)" -days $((365 * 10)) -extensions usr_cert \
-out /dev/stdout >> "$tmp" &&
mv "$tmp" smtpd.pem

provided that same "openssl.cnf" has the usual "usr_cert" section
as well as the inconvenient "v3_ca" section with:

basicConstraints = CA:true

or

basicConstraints = critical,CA:true

--
Viktor.

[Robert Moskowitz]

On 01/04/2013 11:38 AM, Viktor Dukhovni wrote:
> On Fri, Jan 04, 2013 at 12:57:00AM -0500, Robert Moskowitz wrote:
>
>>>> I was noticing an error in /var/log/httpd/ssl_error_log about the
>>>> cert having basicConstraints: CA=TRUE
>>> If some HTTP server does not like self-signed SSL certs with CA=TRUE,
>>> that's its own problem. Postfix will not force you to jump through
>>> such pointless hoops.
>> It was a warning. More likely it would be the clients that would
>> object. Postfix may be happy with such a cert, but some other MTA
>> or client might not accept such a cert from Postfix.
>>
>> One of the IETF mantras is "be conservative in what you send and
>> liberal in what you accept". So a client SHOULD accept this, but
>> not MUST accept it. A server MAY send it, but SHOULD avoid it.
> There is nothing wrong with "CA:true" in a self-signed SSL certificate.

By some definitions of 'wrong' :)

You may not have attended the same sort of PKI policy meetings that I
lived through! But since this is in large measure a policy issue, we
will leave it there.

> If, however, your default "openssl.cnf" adds "CA:true", and you'd rather
> not have it present, the "one liner" can be updated slightly to:
>
> # tmp=$(mktemp smptpd.pem.XXXXXX) &&
> openssl req -new \
> -newkey rsa:1280 -keyout "$tmp" -nodes \
> -x509 -subj "/CN=$(uname -n)" -days $((365 * 10)) -extensions usr_cert \
> -out /dev/stdout >> "$tmp" &&
> mv "$tmp" smtpd.pem
>
> provided that same "openssl.cnf" has the usual "usr_cert" section
> as well as the inconvenient "v3_ca" section with:
>
> basicConstraints = CA:true
>
> or
>
> basicConstraints = critical,CA:true
>

I will test with user_cert over v3_req that I learned about over on the
OpenSSL list. See how they compare.

Thank you.

[Viktor Dukhovni]

On Fri, Jan 04, 2013 at 12:30:50PM -0500, Robert Moskowitz wrote:

> >There is nothing wrong with "CA:true" in a self-signed SSL certificate.
>
> By some definitions of 'wrong' :)
>
> You may not have attended the same sort of PKI policy meetings that
> I lived through! But since this is in large measure a policy issue,
> we will leave it there.

What meetings you happened to attend is of no consequence.

> I will test with user_cert over v3_req that I learned about over on
> the OpenSSL list. See how they compare.

It is "usr_cert", not "user_cert". The difference in the resulting
extensions is:

v3_req:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment

usr_cert:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
AD:3C:28:E3:E5:B5:F3:0A:5C:63:AB:08:15:4E:1C:42:A3:D5:83:E6
X509v3 Authority Key Identifier:
keyid:AD:3C:28:E3:E5:B5:F3:0A:5C:63:AB:08:15:4E:1C:42:A3:D5:83:E6

default (v3_ca):
X509v3 Subject Key Identifier:
EC:1C:FE:EE:26:9E:09:44:8C:75:5C:F7:1E:38:32:4A:FA:93:FA:E6
X509v3 Authority Key Identifier:
keyid:EC:1C:FE:EE:26:9E:09:44:8C:75:5C:F7:1E:38:32:4A:FA:93:FA:E6
X509v3 Basic Constraints:
CA:TRUE

Perhaps of the three "v3_req" is the closest to a sensible set of
extensions for an endpoint certificate.

--
Viktor.