smtp_tls_CAfile and smtp_tls_CApath doc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

smtp_tls_CAfile and smtp_tls_CApath doc

bitozoid
As of today, doc says for 'smtp_tls_CAfile':

"A file containing CA certificates of root CAs trusted to sign either
remote SMTP server certificates or intermediate CA certificates."

and for 'smtp_tls_CApath':

"Directory with PEM format Certification Authority certificates that
the Postfix SMTP client uses to verify a remote SMTP server
certificate."

On one hand, it looks that a remote server intermediate CA certificate
(think about a remote server that does not send its intermediate CA
certificate) does not fit in 'smtp_tls_CAfile' but in
'smtp_tls_CApath'.

On the other hand, it looks that both variables do the same job, but
one of them from a file and the other from a directory. Moreover, I
have appended an intermediate CA certificate to 'smtp_tls_CAfile' and
it seems to work for a remote server that does not provide it.

Am I misunderstanding the documentation? Is there a right place to
drop the intermediate CA certificate?
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_CAfile and smtp_tls_CApath doc

Matus UHLAR - fantomas
On 11.02.21 14:51, bitozoid wrote:

>As of today, doc says for 'smtp_tls_CAfile':
>
>"A file containing CA certificates of root CAs trusted to sign either
>remote SMTP server certificates or intermediate CA certificates."
>
>and for 'smtp_tls_CApath':
>
>"Directory with PEM format Certification Authority certificates that
>the Postfix SMTP client uses to verify a remote SMTP server
>certificate."
>
>On one hand, it looks that a remote server intermediate CA certificate
>(think about a remote server that does not send its intermediate CA
>certificate) does not fit in 'smtp_tls_CAfile' but in
>'smtp_tls_CApath'.

huh?

>On the other hand, it looks that both variables do the same job, but
>one of them from a file and the other from a directory. Moreover, I
>have appended an intermediate CA certificate to 'smtp_tls_CAfile' and
>it seems to work for a remote server that does not provide it.
>
>Am I misunderstanding the documentation? Is there a right place to
>drop the intermediate CA certificate?

both smtp_tls_CAfile and smtp_tls_CApath are designed to contain
list of trusted CAs for SSL-based authentication.

However, smtp_tls_CAfile can be used for providing intermediate certificate,
which chould not be a problem if you don't use SSL authentication.

Postfix >= 3.4 supports directive smtpd_tls_chain_files, which contains list
of files containing private key, certificate and intermediate authorities
(contatenated).

Posttfix <= 3.3 supports multiple directives smtpd_tls_cert_file
smtpd_tls_key_file, smtpd_tls_eccert_file, smtpd_tls_eckey_file

supposed to contain certificates and keys. Certificates can be
concatenated in cert files, which can also include private keys.

http://www.postfix.org/TLS_README.html

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_CAfile and smtp_tls_CApath doc

bitozoid

On Thu, Feb 11, 2021 at 3:11 PM Matus UHLAR - fantomas <[hidden email]> wrote:
On 11.02.21 14:51, bitozoid wrote:
>As of today, doc says for 'smtp_tls_CAfile':
>
>"A file containing CA certificates of root CAs trusted to sign either
>remote SMTP server certificates or intermediate CA certificates."
>
>and for 'smtp_tls_CApath':
>
>"Directory with PEM format Certification Authority certificates that
>the Postfix SMTP client uses to verify a remote SMTP server
>certificate."
>
>On one hand, it looks that a remote server intermediate CA certificate
>(think about a remote server that does not send its intermediate CA
>certificate) does not fit in 'smtp_tls_CAfile' but in
>'smtp_tls_CApath'.

huh?

'smtp_tls_CAfile' doc just mentions "root CAs" for the content of the file.
 
>On the other hand, it looks that both variables do the same job, but
>one of them from a file and the other from a directory. Moreover, I
>have appended an intermediate CA certificate to 'smtp_tls_CAfile' and
>it seems to work for a remote server that does not provide it.
>
>Am I misunderstanding the documentation? Is there a right place to
>drop the intermediate CA certificate?

both smtp_tls_CAfile and smtp_tls_CApath are designed to contain
list of trusted CAs for SSL-based authentication.

However, smtp_tls_CAfile can be used for providing intermediate certificate,
which chould not be a problem if you don't use SSL authentication.

I don't understand what you mean in your last sentence.
 
Postfix >= 3.4 supports directive smtpd_tls_chain_files, which contains list
of files containing private key, certificate and intermediate authorities
(contatenated).

Posttfix <= 3.3 supports multiple directives smtpd_tls_cert_file
smtpd_tls_key_file, smtpd_tls_eccert_file, smtpd_tls_eckey_file

supposed to contain certificates and keys. Certificates can be
concatenated in cert files, which can also include private keys.

I guess those are for postfix as an SMTP server. My question is for postfix as an SMTP client.

Thanks a lot for your answer.
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_CAfile and smtp_tls_CApath doc

Matus UHLAR - fantomas
>> On 11.02.21 14:51, bitozoid wrote:
>> >As of today, doc says for 'smtp_tls_CAfile':
>> >
>> >"A file containing CA certificates of root CAs trusted to sign either
>> >remote SMTP server certificates or intermediate CA certificates."
>> >
>> >and for 'smtp_tls_CApath':
>> >
>> >"Directory with PEM format Certification Authority certificates that
>> >the Postfix SMTP client uses to verify a remote SMTP server
>> >certificate."
>> >
>> >On one hand, it looks that a remote server intermediate CA certificate
>> >(think about a remote server that does not send its intermediate CA
>> >certificate) does not fit in 'smtp_tls_CAfile' but in
>> >'smtp_tls_CApath'.

>On Thu, Feb 11, 2021 at 3:11 PM Matus UHLAR - fantomas <[hidden email]>
>wrote:
>> huh?

On 11.02.21 16:01, bitozoid wrote:
>'smtp_tls_CAfile' doc just mentions "root CAs" for the content of the file.

yes. smtp_tls_CAfile and smtp_tls_CApath are for the same usage, but smtp_tls_CAfile
is expected to be a file, while smtp_tls_CApath is a path in which multiple
files may be located.

it's easier to maintain a path, however, Debian and derivatived generate the
file when you run update-ca-certificates.

>> >On the other hand, it looks that both variables do the same job, but
>> >one of them from a file and the other from a directory. Moreover, I
>> >have appended an intermediate CA certificate to 'smtp_tls_CAfile' and
>> >it seems to work for a remote server that does not provide it.
>> >
>> >Am I misunderstanding the documentation? Is there a right place to
>> >drop the intermediate CA certificate?
>>
>> both smtp_tls_CAfile and smtp_tls_CApath are designed to contain
>> list of trusted CAs for SSL-based authentication.
>>
>> However, smtp_tls_CAfile can be used for providing intermediate
>> certificate,
>> which chould not be a problem if you don't use SSL authentication.

>I don't understand what you mean in your last sentence.

if you put your server's certificate into smtpd_tls_cert_file and
intermediate certificate to smtp_tls_CAfile, the intermediate certificate
will be provided to clients.

smtp_tls_CAfile will still be used as list of authorities trusted to sign
clients' certificates, which may be a problem if you use ssl-based
authentication.


>> Postfix >= 3.4 supports directive smtpd_tls_chain_files, which contains
>> list
>> of files containing private key, certificate and intermediate authorities
>> (contatenated).
>>
>> Posttfix <= 3.3 supports multiple directives smtpd_tls_cert_file
>> smtpd_tls_key_file, smtpd_tls_eccert_file, smtpd_tls_eckey_file
>>
>> supposed to contain certificates and keys. Certificates can be
>> concatenated in cert files, which can also include private keys.


> I guess those are for postfix as an SMTP server. My question is for
>postfix as an SMTP client.

smtpd_tls_* are for postfix as smtp server,
smtp_tls_* are for postfix as smtp client.

does your postfix authenticate to other servers using SSL certificate?

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states.
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_CAfile and smtp_tls_CApath doc

Viktor Dukhovni
In reply to this post by bitozoid
On Thu, Feb 11, 2021 at 02:51:02PM +0000, bitozoid wrote:

> As of today, doc says for 'smtp_tls_CAfile':
>
> "A file containing CA certificates of root CAs trusted to sign either
> remote SMTP server certificates or intermediate CA certificates."

It can also contain intermediate CA certificates.  Storing non-root CAs
carries a risk that they may expire before you remove them, and then
they may take precedence over non-expired intermediate CA certs that the
remote peer provides in the TLS handshake.

TLS servers or clients that fail to send the required list of
intermediate certificates are in violation of various RFCs, and poor
interoperability is to be expected.  Perhaps a better fix is to request
that the problem be fixed on the remote end.

> and for 'smtp_tls_CApath':
>
> "Directory with PEM format Certification Authority certificates that
> the Postfix SMTP client uses to verify a remote SMTP server
> certificate."

They're basically the same, with the key difference that CAfile is
preloaded into memory in its entirety, while CApath is demand loaded,
one certificate at a time.

You can also use the "tafile" option in the TLS policy table to specify
explicit per-destination trust-anchors that override CAfile and CApath.
The trust-anchors in the "tafile" can even be bare public keys (e.g.
output of "openssl x509 -in cert.pem -pubkey -noout"), rather than
certificates, and thus never explicitly "expire", it is then up to you
to remove them as/when you see fit.

> On one hand, it looks that a remote server intermediate CA certificate
> (think about a remote server that does not send its intermediate CA
> certificate) does not fit in 'smtp_tls_CAfile' but in
> 'smtp_tls_CApath'.

both support the same types of certificates.

> Am I misunderstanding the documentation? Is there a right place to
> drop the intermediate CA certificate?

With an empty CAfile, and just CApath, you reduce startup overhead,
by delaying certificate loading until they're needed.  When running
the SMTP client chrooted, the CApath needs to be *inside* the chroot
jail.  If the CAfile is large enough, CApath is the better option.

If preloading the CAfile is sufficiently cheap (a few dozen
certificates), it may be simpler w.r.t. to chroot etc., than CApath.

On a busy server, the cost of loading the file is paid every $max_use
deliveries (i.e. once per smtp(8) process), and the content is in memory
up to as many times as the sum of the various smtp delivery agent
process limits in master.cf (perhaps $default_process_limit * 2, once
for "smtp/unix" and once for "relay/unix").

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_CAfile and smtp_tls_CApath doc

bitozoid
On Thu, Feb 11, 2021 at 4:49 PM Viktor Dukhovni
<[hidden email]> wrote:

>
> On Thu, Feb 11, 2021 at 02:51:02PM +0000, bitozoid wrote:
>
> > As of today, doc says for 'smtp_tls_CAfile':
> >
> > "A file containing CA certificates of root CAs trusted to sign either
> > remote SMTP server certificates or intermediate CA certificates."
>
> It can also contain intermediate CA certificates.  Storing non-root CAs
> carries a risk that they may expire before you remove them, and then
> they may take precedence over non-expired intermediate CA certs that the
> remote peer provides in the TLS handshake.
>
> TLS servers or clients that fail to send the required list of
> intermediate certificates are in violation of various RFCs, and poor
> interoperability is to be expected.  Perhaps a better fix is to request
> that the problem be fixed on the remote end.
>

That is really insightful. That would also be nice to be found in the doc.

Thanks a lot.
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_CAfile and smtp_tls_CApath doc

Viktor Dukhovni
On Thu, Feb 11, 2021 at 05:04:24PM +0000, bitozoid wrote:

> > It can also contain intermediate CA certificates.  Storing non-root CAs
> > carries a risk that they may expire before you remove them, and then
> > they may take precedence over non-expired intermediate CA certs that the
> > remote peer provides in the TLS handshake.
> >
> > TLS servers or clients that fail to send the required list of
> > intermediate certificates are in violation of various RFCs, and poor
> > interoperability is to be expected.  Perhaps a better fix is to request
> > that the problem be fixed on the remote end.
> >
>
> That is really insightful. That would also be nice to be found in the doc.

Does the below meet your needs?

--- a/proto/postconf.proto
+++ b/proto/postconf.proto
@@ -9486,6 +9486,14 @@ file may also be used to augment the server certificate trust chain,
 but it is best to include all the required certificates directly in the
 server certificate file. </p>
 
+<p> Intermediate CA certificates often have substantially shorter
+lifetimes than their ultimate issuing root CAs.  If you choose to
+include intermediate CAs in your CAfile, make sure to replace them prior
+to expiration.  Otherwise, expired intermediate certificates in the
+trust store may take precedence over fresh copies provided by a properly
+configured peer as part of the TLS handshake, this may result in failure
+to validate the peer's certificate chain. </p>
+
 <p> Specify "smtpd_tls_CAfile = /path/to/system_CA_file" to use ONLY
 the system-supplied default Certification Authority certificates.
 </p>
@@ -9500,7 +9508,7 @@ of client certificates, the distinguished names (DNs) of the Certification
 Authorities listed in smtpd_tls_CAfile are sent to the remote SMTP client
 in the client certificate request message. MUAs with multiple client
 certificates may use the list of preferred Certification Authorities
-to select the correct client certificate.  You may want to put your
+to select the correct client certificate.  You may want to put only your
 "preferred" CA or CAs in this file, and install other trusted CAs in
 $smtpd_tls_CApath. </p>
 
@@ -9521,6 +9529,14 @@ for example, "$OPENSSL_HOME/bin/c_rehash /etc/postfix/certs". To use
 smtpd_tls_CApath in chroot mode, this directory (or a copy) must be
 inside the chroot jail. </p>
 
+<p> Intermediate CA certificates often have substantially shorter
+lifetimes than their ultimate issuing root CAs.  If you choose to
+include intermediate CAs in your CApath, make sure to replace them prior
+to expiration.  Otherwise, expired intermediate certificates in the
+trust store may take precedence over fresh copies provided by a properly
+configured peer as part of the TLS handshake, this may result in failure
+to validate the peer's certificate chain. </p>
+
 <p> Specify "smtpd_tls_CApath = /path/to/system_CA_directory" to
 use ONLY the system-supplied default Certification Authority certificates.
 </p>
@@ -9966,6 +9982,19 @@ file may also be used to augment the client certificate trust chain,
 but it is best to include all the required certificates directly in
 $smtp_tls_cert_file (or, Postfix &ge; 3.4 $smtp_tls_chain_files). </p>
 
+<p> Intermediate CA certificates often have substantially shorter
+lifetimes than their ultimate issuing root CAs.  If you choose to
+include intermediate CAs in your CAfile, make sure to replace them prior
+to expiration.  Otherwise, expired intermediate certificates in the
+trust store may take precedence over fresh copies provided by a properly
+configured peer as part of the TLS handshake, this may result in failure
+to validate the peer's certificate chain. </p>
+
+<p> The choice between $smtp_tls_CAfile and $smtp_tls_CApath is a
+space/time tradeoff. If there are many trusted CAs, the cost of
+preloading them all into memory (from a CAfile) may not pay off in
+reduced access time when the certificate is needed.  </p>
+
 <p> Specify "smtp_tls_CAfile = /path/to/system_CA_file" to use
 ONLY the system-supplied default Certification Authority certificates.
 </p>
@@ -9993,6 +10022,19 @@ with, for example, "$OPENSSL_HOME/bin/c_rehash /etc/postfix/certs".
 <p> To use this option in chroot mode, this directory (or a copy)
 must be inside the chroot jail. </p>
 
+<p> Intermediate CA certificates often have substantially shorter
+lifetimes than their ultimate issuing root CAs.  If you choose to
+include intermediate CAs in your CApath, make sure to replace them prior
+to expiration.  Otherwise, expired intermediate certificates in the
+trust store may take precedence over fresh copies provided by a properly
+configured peer as part of the TLS handshake, this may result in failure
+to validate the peer's certificate chain. </p>
+
+<p> The choice between $smtp_tls_CAfile and $smtp_tls_CApath is a
+space/time tradeoff. If there are many trusted CAs, the cost of
+preloading them all into memory (from a CAfile) may not pay off in
+reduced access time when the certificate is needed.  </p>
+
 <p> Specify "smtp_tls_CApath = /path/to/system_CA_directory" to
 use ONLY the system-supplied default Certification Authority certificates.
 </p>
@@ -12464,7 +12506,7 @@ SHA256 Fingerprint=D4:6A:AB:19:24:...:BB:A6:CB:66:82:C0:8E:9B:EE:29:A8:1A
 you need to extract the public key from the certificate and compute
 the appropriate digest of its DER (ASN.1) encoding. With OpenSSL
 the "-pubkey" option of the "x509" command extracts the public
-key always in "PEM" format. We pipe the result to another OpenSSL
+key always in PEM format. We pipe the result to another OpenSSL
 command that converts the key to DER and then to the "dgst" command
 to compute the fingerprint. </p>
 
@@ -12606,7 +12648,7 @@ SHA256 Fingerprint=D4:6A:AB:19:24:...:A6:CB:66:82:C0:8E:9B:EE:29:A8:1A
 you need to extract the public key from the certificate and compute
 the appropriate digest of its DER (ASN.1) encoding. With OpenSSL
 the "-pubkey" option of the "x509" command extracts the public
-key always in "PEM" format. We pipe the result to another OpenSSL
+key always in PEM format. We pipe the result to another OpenSSL
 command that converts the key to DER and then to the "dgst" command
 to compute the fingerprint. </p>
 
--- a/proto/TLS_README.html
+++ b/proto/TLS_README.html
@@ -150,7 +150,7 @@ key configuration </a>
 key configuration </a> </h3>
 
 <p> In order to use TLS, the Postfix SMTP server generally needs
-a certificate and a private key. Both must be in "PEM" format. The
+a certificate and a private key. Both must be in PEM format. The
 private key must not be encrypted, meaning:  the key must be accessible
 without a password.  The certificate and private key may be in the same
 file, in which case the certificate file should be owned by "root" and
@@ -372,7 +372,7 @@ anonymous-cipher capable clients: </p>
 
 <p> To verify a remote SMTP client certificate, the Postfix SMTP
 server needs to trust the certificates of the issuing Certification
-Authorities. These certificates in "PEM" format can be stored in a
+Authorities. These certificates in PEM format can be stored in a
 single $smtpd_tls_CAfile or in multiple files, one CA per file in
 the $smtpd_tls_CApath directory. If you use a directory, don't forget
 to create the necessary "hash" links with: </p>
@@ -849,7 +849,7 @@ the name of the user or host:</p>
 you need to extract the public key from the certificate and compute
 the appropriate digest of its DER (ASN.1) encoding. With OpenSSL
 the "-pubkey" option of the "x509" command extracts the public
-key always in "PEM" format. We pipe the result to another OpenSSL
+key always in PEM format. We pipe the result to another OpenSSL
 command that converts the key to DER and then to the "dgst" command
 to compute the fingerprint. </p>
 
@@ -1551,7 +1551,7 @@ As in the example above, we show two matching fingerprints: </p>
 you need to extract the public key from the certificate and compute
 the appropriate digest of its DER (ASN.1) encoding. With OpenSSL
 the "-pubkey" option of the "x509" command extracts the public
-key always in "PEM" format. We pipe the result to another OpenSSL
+key always in PEM format. We pipe the result to another OpenSSL
 command that converts the key to DER and then to the "dgst" command
 to compute the fingerprint. </p>
 
@@ -1861,7 +1861,7 @@ cipher used determines which certificate is presented. </p>
 
 <p> It is possible for the Postfix SMTP client to use the same
 key/certificate pair as the Postfix SMTP server.  If a certificate
-is to be presented, it must be in "PEM" format. The private key
+is to be presented, it must be in PEM format. The private key
 must not be encrypted, meaning: it must be accessible without
 password. Both parts (certificate and private key) may be in the
 same file. </p>
@@ -1987,7 +1987,7 @@ above. <p>
 
 <p> To verify a remote SMTP server certificate, the Postfix SMTP
 client needs to trust the certificates of the issuing Certification
-Authorities. These certificates in "pem" format can be stored in a
+Authorities. These certificates in PEM format can be stored in a
 single $smtp_tls_CAfile or in multiple files, one CA per file in
 the $smtp_tls_CApath directory. If you use a directory, don't forget
 to create the necessary "hash" links with: </p>

--
    Viktor.