Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: OpenSSL: TXT_DB error number 2
106 views
Skip to first unread message
thor...@lavabit.com
Nov 18, 2012, 5:13:05 AM11/18/12
to
> This will write a new 1280-bit RSA key and the corresponding
> self-signed certificate with server name "mail.example.com" valid
> for ~10 years to the file /etc/postfix/smtpd.pem, which you can
> use as the server certificate (and implicitly key) file:
Should I specify it like this?
smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_key_file = /etc/postfix/smtpd.pem
There is a line from a previous setup:
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
Can I remove it?
> Support for elliptic curve cryptography is available with Postfix
> 2.6 and OpenSSL 0.9.9 or later.
OpenSSL 0.9.8 supports it too.
Viktor, thank you so much for your help.
> self-signed certificate with server name "mail.example.com" valid
> for ~10 years to the file /etc/postfix/smtpd.pem, which you can
> use as the server certificate (and implicitly key) file:
Should I specify it like this?
smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_key_file = /etc/postfix/smtpd.pem
There is a line from a previous setup:
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
Can I remove it?
> Support for elliptic curve cryptography is available with Postfix
> 2.6 and OpenSSL 0.9.9 or later.
OpenSSL 0.9.8 supports it too.
Viktor, thank you so much for your help.
thor...@lavabit.com
Nov 18, 2012, 8:38:39 AM11/18/12
to
"smtpd_tls_eecdh_grade (default: see "postconf -d" output)
<snip>
This feature is available in Postfix 2.6 and later, when it is
compiled and linked with OpenSSL 1.0.0 or later." [0]
I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
dependencies.
"postconf -d" lists this option. Does it mean that it's supported?
--
I read some articles about Diffie-Hellman Key Exchange. What I don't
understand is the connection between theory and its practical
implementation.
For example, this article [1] says that it's necessary to have a
key pair on a client machine. But this one [2] doesn't say anything
regarding clients. Is it necessary to configure clients? Will it be
handled automatically (by OpenSSL)?
Will smtpd.pem be used to certify public keys or authorize a server? Will
it be
used to encrypt a shared secret? What key will be used to decrypt the
shared secret (on the client)?
What is the purpose of DH parameters? What are export and non-export
ciphers? [2]
[0] http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade
[1]
http://www.packetsource.com/article/encryption/40070/diffie-hellman-key-exchange-a-non-mathematicians-explanation
[2] http://www.postfix.org/TLS_README.html#server_cipher
<snip>
This feature is available in Postfix 2.6 and later, when it is
compiled and linked with OpenSSL 1.0.0 or later." [0]
I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
dependencies.
"postconf -d" lists this option. Does it mean that it's supported?
--
I read some articles about Diffie-Hellman Key Exchange. What I don't
understand is the connection between theory and its practical
implementation.
For example, this article [1] says that it's necessary to have a
key pair on a client machine. But this one [2] doesn't say anything
regarding clients. Is it necessary to configure clients? Will it be
handled automatically (by OpenSSL)?
Will smtpd.pem be used to certify public keys or authorize a server? Will
it be
used to encrypt a shared secret? What key will be used to decrypt the
shared secret (on the client)?
What is the purpose of DH parameters? What are export and non-export
ciphers? [2]
[0] http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade
[1]
http://www.packetsource.com/article/encryption/40070/diffie-hellman-key-exchange-a-non-mathematicians-explanation
[2] http://www.postfix.org/TLS_README.html#server_cipher
Viktor Dukhovni
Nov 18, 2012, 2:17:09 PM11/18/12
to
On Sun, Nov 18, 2012 at 05:13:05AM -0500, thor...@lavabit.com wrote:
> > This will write a new 1280-bit RSA key and the corresponding
> > self-signed certificate with server name "mail.example.com" valid
> > for ~10 years to the file /etc/postfix/smtpd.pem, which you can
> > use as the server certificate (and implicitly key) file:
>
> Should I specify it like this?
>
> smtpd_tls_cert_file = /etc/postfix/smtpd.pem
> smtpd_tls_key_file = /etc/postfix/smtpd.pem
The second setting is optional, since the default is:
> > This will write a new 1280-bit RSA key and the corresponding
> > self-signed certificate with server name "mail.example.com" valid
> > for ~10 years to the file /etc/postfix/smtpd.pem, which you can
> > use as the server certificate (and implicitly key) file:
>
> Should I specify it like this?
>
> smtpd_tls_cert_file = /etc/postfix/smtpd.pem
> smtpd_tls_key_file = /etc/postfix/smtpd.pem
$ postconf -d smtpd_tls_key_file
smtpd_tls_key_file = $smtpd_tls_cert_file
> There is a line from a previous setup:
>
> smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
>
> Can I remove it?
> > Support for elliptic curve cryptography is available with Postfix
> > 2.6 and OpenSSL 0.9.9 or later.
>
> OpenSSL 0.9.8 supports it too.
when compiled and linked with OpenSSL 1.0.0 or later. If the text
mentioning 0.9.9 is from Postfix documentation, we should update
it, there was never an OpenSSL 0.9.9 release, only development
snapshots.
--
Viktor.
Viktor Dukhovni
Nov 18, 2012, 2:27:21 PM11/18/12
to
On Sun, Nov 18, 2012 at 08:38:39AM -0500, thor...@lavabit.com wrote:
> "smtpd_tls_eecdh_grade (default: see "postconf -d" output)
>
> <snip>
>
> This feature is available in Postfix 2.6 and later, when it is
> compiled and linked with OpenSSL 1.0.0 or later." [0]
>
> I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
> dependencies.
>
> "postconf -d" lists this option. Does it mean that it's supported?
No, Postfix with elliptic curve DH requires OpenSSL 1.0.0. However,
> "smtpd_tls_eecdh_grade (default: see "postconf -d" output)
>
> <snip>
>
> This feature is available in Postfix 2.6 and later, when it is
> compiled and linked with OpenSSL 1.0.0 or later." [0]
>
> I'm using Postfix 2.7.1. "aptitude show postfix" shows libssl0.9.8 in
> dependencies.
>
> "postconf -d" lists this option. Does it mean that it's supported?
you can still use regular 1024-bit prime DH, preferably by generating
non-default DH parameters, although in practice it is likely that
the default prime group compiled into Postfix has not yet been
brute-forced. Thus lack of elliptic curve support is not critical.
src/tls/tls_dh.c:
/*
* Generated via "openssl dhparam -2 -noout -C 512 2>/dev/null" TODO:
* generate at compile-time.
*/
static unsigned char dh512_p[] = {
0x88, 0x3F, 0x00, 0xAF, 0xFC, 0x0C, 0x8A, 0xB8, 0x35, 0xCD, 0xE5, 0xC2,
0x0F, 0x55, 0xDF, 0x06, 0x3F, 0x16, 0x07, 0xBF, 0xCE, 0x13, 0x35, 0xE4,
0x1C, 0x1E, 0x03, 0xF3, 0xAB, 0x17, 0xF6, 0x63, 0x50, 0x63, 0x67, 0x3E,
0x10, 0xD7, 0x3E, 0xB4, 0xEB, 0x46, 0x8C, 0x40, 0x50, 0xE6, 0x91, 0xA5,
0x6E, 0x01, 0x45, 0xDE, 0xC9, 0xB1, 0x1F, 0x64, 0x54, 0xFA, 0xD9, 0xAB,
0x4F, 0x70, 0xBA, 0x5B,
};
/*
* Generated via "openssl dhparam -2 -noout -C 1024 2>/dev/null" TODO:
* generate at compile-time.
*/
static unsigned char dh1024_p[] = {
0xB0, 0xFE, 0xB4, 0xCF, 0xD4, 0x55, 0x07, 0xE7, 0xCC, 0x88, 0x59, 0x0D,
0x17, 0x26, 0xC5, 0x0C, 0xA5, 0x4A, 0x92, 0x23, 0x81, 0x78, 0xDA, 0x88,
0xAA, 0x4C, 0x13, 0x06, 0xBF, 0x5D, 0x2F, 0x9E, 0xBC, 0x96, 0xB8, 0x51,
0x00, 0x9D, 0x0C, 0x0D, 0x75, 0xAD, 0xFD, 0x3B, 0xB1, 0x7E, 0x71, 0x4F,
0x3F, 0x91, 0x54, 0x14, 0x44, 0xB8, 0x30, 0x25, 0x1C, 0xEB, 0xDF, 0x72,
0x9C, 0x4C, 0xF1, 0x89, 0x0D, 0x68, 0x3F, 0x94, 0x8E, 0xA4, 0xFB, 0x76,
0x89, 0x18, 0xB2, 0x91, 0x16, 0x90, 0x01, 0x99, 0x66, 0x8C, 0x53, 0x81,
0x4E, 0x27, 0x3D, 0x99, 0xE7, 0x5A, 0x7A, 0xAF, 0xD5, 0xEC, 0xE2, 0x7E,
0xFA, 0xED, 0x01, 0x18, 0xC2, 0x78, 0x25, 0x59, 0x06, 0x5C, 0x39, 0xF6,
0xCD, 0x49, 0x54, 0xAF, 0xC1, 0xB1, 0xEA, 0x4A, 0xF9, 0x53, 0xD0, 0xDF,
0x6D, 0xAF, 0xD4, 0x93, 0xE7, 0xBA, 0xAE, 0x9B,
};
--
Viktor.
Wietse Venema
Nov 18, 2012, 2:31:08 PM11/18/12
to
Viktor Dukhovni:
Wietse
> text mentioning 0.9.9 is from Postfix documentation, we should
> update it, there was never an OpenSSL 0.9.9 release, only development
> snapshots.
Fixed in the next release.
> update it, there was never an OpenSSL 0.9.9 release, only development
> snapshots.
Wietse
thor...@lavabit.com
Nov 19, 2012, 3:48:14 PM11/19/12
to
I applied the suggested changes and decided to test the server.
"openssl s_client -tls1 -connect mail.example.com:25" returned
"SSL3_GET_RECORD:wrong version number". What is the problem?
"openssl s_client -tls1 -connect mail.example.com:25" returned
"SSL3_GET_RECORD:wrong version number". What is the problem?
Wietse Venema
Nov 19, 2012, 4:03:15 PM11/19/12
to
thor...@lavabit.com:
The result: one ends of the connection wants to talk SSLv3 and the
other end supports only TLSv1.
Wietse
> I applied the suggested changes and decided to test the server.
>
> "openssl s_client -tls1 -connect mail.example.com:25" returned
> "SSL3_GET_RECORD:wrong version number". What is the problem?
Stuff the error message into a search engine.
>
> "openssl s_client -tls1 -connect mail.example.com:25" returned
> "SSL3_GET_RECORD:wrong version number". What is the problem?
The result: one ends of the connection wants to talk SSLv3 and the
other end supports only TLSv1.
Wietse
Viktor Dukhovni
Nov 19, 2012, 4:06:17 PM11/19/12
to
On Mon, Nov 19, 2012 at 03:48:14PM -0500, thor...@lavabit.com wrote:
> I applied the suggested changes and decided to test the server.
>
> "openssl s_client -tls1 -connect mail.example.com:25" returned
> "SSL3_GET_RECORD:wrong version number". What is the problem?
SMTP servers negotiate TLS over SMTP via STARTTLS, you're trying
> I applied the suggested changes and decided to test the server.
>
> "openssl s_client -tls1 -connect mail.example.com:25" returned
> "SSL3_GET_RECORD:wrong version number". What is the problem?
to start the SSL/TLS handshake without the prior SMTP handshake.
You must:
$ openssl s_client -starttls smtp -connect mail.example.com:25
--
Viktor.
Viktor Dukhovni
Nov 19, 2012, 4:10:16 PM11/19/12
to
On Mon, Nov 19, 2012 at 04:03:15PM -0500, Wietse Venema wrote:
> > I applied the suggested changes and decided to test the server.
> >
> > "openssl s_client -tls1 -connect mail.example.com:25" returned
> > "SSL3_GET_RECORD:wrong version number". What is the problem?
>
> > I applied the suggested changes and decided to test the server.
> >
> > "openssl s_client -tls1 -connect mail.example.com:25" returned
> > "SSL3_GET_RECORD:wrong version number". What is the problem?
>
> Stuff the error message into a search engine.
>
> The result: one ends of the connection wants to talk SSLv3 and the
> other end supports only TLSv1.
In this case the problem is deeper, one end is not even talking
>
> The result: one ends of the connection wants to talk SSLv3 and the
> other end supports only TLSv1.
SSL/TLS, the "wrong version number" is a bit of a red-herring, an
SMTP banner is misreported as an SSL record layer header with an
unexpected protocol version.
Avoiding this problem would have required a more bloated TLS record
layer, so better reporting is not easy.
--
Viktor.
Viktor Dukhovni
Nov 20, 2012, 10:23:22 AM11/20/12
to
On Tue, Nov 20, 2012 at 07:25:11AM -0500, ci...@lavabit.com wrote:
> > SMTP servers negotiate TLS over SMTP via STARTTLS, you're trying
> > to start the SSL/TLS handshake without the prior SMTP handshake.
> > You must:
>
> > $ openssl s_client -starttls smtp -connect mail.example.com:25
>
> The above command returned
> > SMTP servers negotiate TLS over SMTP via STARTTLS, you're trying
> > to start the SSL/TLS handshake without the prior SMTP handshake.
> > You must:
>
> > $ openssl s_client -starttls smtp -connect mail.example.com:25
>
>
> SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
Check the server logs. This works when "mail.example.com" (that is
is whatever you're actually testing) is replaced by mx.lavabit.com.
> There is one thing I forgot to ask when we discussed DH keys and certs.
> Should I also alter courier config?
At no point did I suggest creating DH certificates, neither for
Postfix nor for any other software. EDH Key Exchange is NOT
certificate authentication, nobody uses DH certs, continue to
use RSA.
[For the record, in private peering arrangements I've sometimes
used ECDSA, but that won't work too well on the public internet,
for Internet facing SMTP servers one always needs at least RSA,
and given the OPs level of experience with SSL, ... I would not
recommend adventurous multi-certificate configurations]
> There are related fields:
>
> TLS_DHCERTFILE=
> TLS_CERTFILE=/usr/lib/courier/imapd.pem
> TLS_TRUSTCERTS=/etc/ssl/certs
>
> Should I point TLS_DHCERTFILE to /etc/postfix/smtpd.pem?
NO. Do not use DH certificates, use RSA. The DH parameter
files you were advised to generate are not certificates.
Your smtpd.pem file should be mode 0600 and contain an
RSA private key and associated self-signed certificate.
> Should I point TLS_CERTFILE to /etc/postfix/smtpd.pem?
> (Postfix uses it as smtpd_tls_cert_file.)
You can use the same certificate for both IMAP and SMTP, if the
same CN (hostname) is used by clients for both protocols.
> Should I point TLS_TRUSTCERTS to /etc/ssl/certs/cacert.pem?
> (Postfix uses the above as smtpd_tls_CAfile.)
You don't need a CA file, your certificate is self-signed.
> imapd.pem was generated with mkimapdcert.
Then you can use that if you like.
> I attached the script and comments connected with options:
I am not going to read it, sorry about that.
--
Viktor.
ci...@lavabit.com
Nov 23, 2012, 7:55:28 PM11/23/12
to
>> > $ openssl s_client -starttls smtp -connect mail.example.com:25
>>
>> The above command returned
>>
>> SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
>
> Check the server logs.
/var/log/mail.info:
>>
>> The above command returned
>>
>> SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
>
> Check the server logs.
warning: cannot get RSA private key from file /etc/postfix/smtpd.pem:
disabling TLS support
warning: TLS library problem ... Expecting: ANY PRIVATE KEY
I used these commands [0] to create smtpd.pem:
# cd /etc/postfix
# tmp=$(mktemp smtpd.pem.XXXXXX)
# openssl req -x509 -new -newkey rsa:1280 -nodes -keyout /dev/stdout \
-days $((365 * 10)) -subj "/CN=mail.example.com" > $tmp
# chmod 0600 $tmp
# mv $tmp smtpd.pem
Why Postfix fail to get a key from smtpd.pem?
main.cf:
smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_key_file = /etc/postfix/smtpd.pem
[0] http://article.gmane.org/gmane.mail.postfix.user/233328
Viktor Dukhovni
Nov 24, 2012, 10:56:33 AM11/24/12
to
On Fri, Nov 23, 2012 at 07:55:28PM -0500, ci...@lavabit.com wrote:
> > > SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
> >
> > Check the server logs.
>
> /var/log/mail.info:
>
> warning: cannot get RSA private key from file /etc/postfix/smtpd.pem:
> disabling TLS support
> warning: TLS library problem ... Expecting: ANY PRIVATE KEY
There is no usable private key in your smtpd.pem configuration file.
> > > SSL routines:SSL23_GET_SERVER_HELLO: unknown protocol
> >
> > Check the server logs.
>
> /var/log/mail.info:
>
> warning: cannot get RSA private key from file /etc/postfix/smtpd.pem:
> disabling TLS support
> warning: TLS library problem ... Expecting: ANY PRIVATE KEY
> I used these commands [0] to create smtpd.pem:
>
> # cd /etc/postfix
> # tmp=$(mktemp smtpd.pem.XXXXXX)
> # openssl req -x509 -new -newkey rsa:1280 -nodes -keyout /dev/stdout \
> -days $((365 * 10)) -subj "/CN=mail.example.com" > $tmp
> # chmod 0600 $tmp
> # mv $tmp smtpd.pem
>
> Why Postfix fail to get a key from smtpd.pem?
not a portable way of getting OpenSSL to output the key and
certificate back-to-back. Did the shell commands in the recipe
generate any error messages?
When I run this and check the contents of the smtpd.pem file (did
you ever look at the file contents? Why not?) I see:
$ egrep '^-----' smtpd.pem
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Which shows the expected key and certificate. Post the output for
your system. You can alsways generate the key separately:
# cd /etc/postfix
# tmp=$(mktemp smtpd.pem.XXXXXX)
# openssl req -x509 -new -key "$tmp" \
-days "$((365 * 10))" -subj "/CN=mail.example.com" >> "$tmp"
# chmod 0600 "$tmp"
# mv "$tmp" smtpd.pem
Don't be so helpless. Take some initiative to follow the clues to their
# chmod 0600 "$tmp"
# mv "$tmp" smtpd.pem
logical conclusions. If the software sees no key in the file, check the
file and figure out what's there, and perhaps why.
--
Viktor.
sl...@lavabit.com
Nov 25, 2012, 7:12:00 AM11/25/12
to
Hello,
> Either you botched the recipe, or the use of "-keyout stdout" is
> not a portable way of getting OpenSSL to output the key and
> certificate back-to-back.
It turned out that my version of genrsa doesn't support the -nodes
option. I removed it and it didn't raise any errors.
> When I run this and check the contents of the smtpd.pem file (did
> you ever look at the file contents? Why not?) I see:
> $ egrep '^-----' smtpd.pem
> -----BEGIN PRIVATE KEY-----
> -----END PRIVATE KEY-----
> -----BEGIN CERTIFICATE-----
> -----END CERTIFICATE-----
It was:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----END PRIVATE KEY-----
I removed the -nodes option and it worked.
CONNECTED(00000003)
depth=0 /CN=mail.example.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=mail.example.com
verify return:1
---
Certificate chain
0 s:/CN=mail.example.com
i:/CN=mail.example.com
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=mail.example.com
issuer=/CN=mail.example.com
---
No client certificate CA names sent
---
...
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1280 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg : None
...
Verify return code: 18 (self signed certificate)
---
250 DSN
read:errno=0
How to debug the above output? Is it OK?
Thank you
> Either you botched the recipe, or the use of "-keyout stdout" is
> not a portable way of getting OpenSSL to output the key and
> certificate back-to-back.
option. I removed it and it didn't raise any errors.
> When I run this and check the contents of the smtpd.pem file (did
> you ever look at the file contents? Why not?) I see:
> $ egrep '^-----' smtpd.pem
> -----BEGIN PRIVATE KEY-----
> -----END PRIVATE KEY-----
> -----BEGIN CERTIFICATE-----
> -----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----END PRIVATE KEY-----
I removed the -nodes option and it worked.
CONNECTED(00000003)
depth=0 /CN=mail.example.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=mail.example.com
verify return:1
---
Certificate chain
0 s:/CN=mail.example.com
i:/CN=mail.example.com
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=mail.example.com
issuer=/CN=mail.example.com
---
No client certificate CA names sent
---
...
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1280 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg : None
...
Verify return code: 18 (self signed certificate)
---
250 DSN
read:errno=0
How to debug the above output? Is it OK?
Thank you
Viktor Dukhovni
Nov 25, 2012, 11:15:41 AM11/25/12
to
On Sun, Nov 25, 2012 at 07:12:00AM -0500, sl...@lavabit.com wrote:
> It turned out that my version of genrsa doesn't support the -nodes
> option. I removed it and it didn't raise any errors.
Actually that's universal, I forgot that while with req(1) encryption
> It turned out that my version of genrsa doesn't support the -nodes
> option. I removed it and it didn't raise any errors.
of the private key is the default and "-nodes" turns it off, with
genrsa(1) no encryption is the default and "-aes128" or similar
turns it on.
> > When I run this and check the contents of the smtpd.pem file (did
> > you ever look at the file contents? Why not?) I see:
>
> > $ egrep '^-----' smtpd.pem
> > -----BEGIN PRIVATE KEY-----
> > -----END PRIVATE KEY-----
> > -----BEGIN CERTIFICATE-----
> > -----END CERTIFICATE-----
>
> It was:
>
> -----BEGIN CERTIFICATE-----
> -----END CERTIFICATE-----
> -----END PRIVATE KEY-----
(but I only tested OpenSSL 1.0.x on BSD-like systems). Thus it is
safer to generate the key and cert in separate command invocations.
> I removed the -nodes option and it worked.
>
> Verify return code: 18 (self signed certificate)
> ---
> 250 DSN
> read:errno=0
>
> How to debug the above output? Is it OK?
Nothing to debug, you're all set.
> ---
> 250 DSN
> read:errno=0
>
> How to debug the above output? Is it OK?
--
Viktor.
Viktor Dukhovni
Nov 26, 2012, 3:28:37 PM11/26/12
to
On Sun, Nov 25, 2012 at 04:15:41PM +0000, Viktor Dukhovni wrote:
> > > When I run this and check the contents of the smtpd.pem file (did
> > > you ever look at the file contents? Why not?) I see:
> >
> > > $ egrep '^-----' smtpd.pem
> > > -----BEGIN PRIVATE KEY-----
> > > -----END PRIVATE KEY-----
> > > -----BEGIN CERTIFICATE-----
> > > -----END CERTIFICATE-----
> >
> > It was:
> >
> > -----BEGIN CERTIFICATE-----
> > -----END CERTIFICATE-----
> > -----END PRIVATE KEY-----
>
> So the output was overlapped, which is different than what I see
> (but I only tested OpenSSL 1.0.x on BSD-like systems). Thus it is
> safer to generate the key and cert in separate command invocations.
For the record, this is brain-damage in linux /dev/fd semantics.
> > > When I run this and check the contents of the smtpd.pem file (did
> > > you ever look at the file contents? Why not?) I see:
> >
> > > $ egrep '^-----' smtpd.pem
> > > -----BEGIN PRIVATE KEY-----
> > > -----END PRIVATE KEY-----
> > > -----BEGIN CERTIFICATE-----
> > > -----END CERTIFICATE-----
> >
> > It was:
> >
> > -----BEGIN CERTIFICATE-----
> > -----END CERTIFICATE-----
> > -----END PRIVATE KEY-----
>
> So the output was overlapped, which is different than what I see
> (but I only tested OpenSSL 1.0.x on BSD-like systems). Thus it is
> safer to generate the key and cert in separate command invocations.
On BSD-like systems and Solaris opening /dev/fd/<number> is equivalent
to calling dup(<number>) and returns a second file descriptor for the
same file:
- The file offset (i.e. open file table slot) is shared
between the original and new descriptor, consecutive
writes on either descriptor are concatentated, and don't
clobber each other.
- Since no new file is opened, the two files are open with
the same mode and no additional permission checks are applied
when opening /dev/fd.
Both of the above are false with Linux. Thus you can EPERM openining
/dev/stdout or /dev/fd/<number> and writes to /dev/stdout followed
by writes to the original standard output do clobber each other unless
one opens stdout with O_APPEND. I consider the Linux semantics broken,
but perhaps I am missing an important design consideration that makes
the Linux semantics correct.
So my one-shot recipe can be adjusted as follows:
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
but this is perhaps over-optimization, and two steps are just fine.
--
Viktor.
0 new messages