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) &&
openssl req -new \
-newkey rsa:$bits -nodes -keyout /dev/stdout \
-x509 -days "$days" -subj "/CN=$fqdn" >> "$tmp" &&
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!
