Re: Achieving trusted TLS connection

> On Feb 1, 2018, at 1:44 PM, Danny Horne wrote: > > Possibly, do I understand right that I'm going to have to separate all > cacerts from the bundle files before using rehash? Yes, but if your OS distribution does not provide a package that handles all this, perhaps you

Re: Achieving trusted TLS connection

On 01/02/2018 6:40 pm, Viktor Dukhovni wrote: > >> On Feb 1, 2018, at 1:26 PM, Danny Horne wrote: >> >> I might have a go at that later (can't find >> c_rehash anywhere but do have csplit available) > https://www.openssl.org/docs/man1.1.0/apps/openssl-rehash.html >

Re: Achieving trusted TLS connection

> On Feb 1, 2018, at 1:26 PM, Danny Horne wrote: > > I might have a go at that later (can't find > c_rehash anywhere but do have csplit available) https://www.openssl.org/docs/man1.1.0/apps/openssl-rehash.html https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html

Re: Achieving trusted TLS connection

On 01/02/2018 5:59 pm, Viktor Dukhovni wrote: > This both loads the default CAfile and sets up the default CApath, so > we don't yet know whether your CApath directory is fully prepared or > not... So now you could try reverting to: > > tls_append_default_CA = no > smtpd_tls_CApath =

Re: Achieving trusted TLS connection

> On Feb 1, 2018, at 12:10 PM, Danny Horne wrote: > >> A simpler way to achieve the same goal would have been: >> http://www.postfix.org/postconf.5.html#tls_append_default_CA >> >> tls_append_default_CA = yes >> >> bearing in mind the caution in the documentation,

Re: Achieving trusted TLS connection

On 1 Feb 2018, at 11:46, Viktor Dukhovni wrote: On Feb 1, 2018, at 11:43 AM, Bill Cole wrote: The "c_rehash" tool is an OpenSSL utility that generates symlinks in a directory full of certificate files such that each symlink name is derived from a

Re: Achieving trusted TLS connection

On 01/02/2018 5:10 pm, Danny Horne wrote: > Ok, adding tls_append_default_CA = yes has finally given me trusted TLS > connections, but I do wonder if it was worth it in the end!! > > I am not using permit_tls_all_clientcerts > I forgot to add, thank you all for your help, though it might not have

Re: Achieving trusted TLS connection

On 01/02/2018 4:56 pm, Viktor Dukhovni wrote: > A simpler way to achieve the same goal would have been: > http://www.postfix.org/postconf.5.html#tls_append_default_CA > > tls_append_default_CA = yes > > bearing in mind the caution in the documentation, when enabling the > panoply of

Re: Achieving trusted TLS connection

> On Feb 1, 2018, at 11:45 AM, Danny Horne wrote: > > # openssl version -d > OPENSSLDIR: "/etc/pki/tls" > > # ls -al /etc/pki/tls > lrwxrwxrwx. 1 root root49 Nov 27 21:00 cert.pem -> > /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem > drwxr-xr-x. 2 root root97 Dec

Re: Achieving trusted TLS connection

> On Feb 1, 2018, at 11:43 AM, Bill Cole > wrote: > > The "c_rehash" tool is an OpenSSL utility that generates symlinks in a > directory full of certificate files such that each symlink name is derived > from a cryptographic hash of the "Subject"

Re: Achieving trusted TLS connection

Ok, didn't fully understand some of what you've said, so I'll just post what I see (no hexadecimal symlinks found).  I've changed smtpd_tls_CApath to /etc/pki/ca-trust/extracted/pem but that hasn't made any difference [root@indium tls]# openssl version -d OPENSSLDIR: "/etc/pki/tls" [root@indium

Re: Achieving trusted TLS connection

On 1 Feb 2018, at 10:44, Danny Horne wrote: I've changed smtpd_tls_CApath back to pointing at the directory.  Not sure what you mean by "hashed" via "c_rehash" The "c_rehash" tool is an OpenSSL utility that generates symlinks in a directory full of certificate files such that each symlink

Re: Achieving trusted TLS connection

> On Feb 1, 2018, at 10:44 AM, Danny Horne wrote: > >> You report settings of: >> smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt >> smtpd_tls_ask_ccert = yes >> smtpd_tls_ccert_verifydepth = 2 >> >> Surely "ca-bundle.trust.crt" is a file not a

Re: Achieving trusted TLS connection

On 31/01/2018 8:31 pm, Viktor Dukhovni wrote: > You report settings of: > smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt > smtpd_tls_ask_ccert = yes > smtpd_tls_ccert_verifydepth = 2 > > Surely "ca-bundle.trust.crt" is a file not a directory. This would work as >

Re: Achieving trusted TLS connection

> On Jan 31, 2018, at 4:12 PM, Bastian Blank > wrote: > > On Wed, Jan 31, 2018 at 03:31:08PM -0500, Viktor Dukhovni wrote: >> Is "SwissSign Silver CA - G2" included in your "ca bundle"? > > Also, is this server known to provide a client cert?

Re: Achieving trusted TLS connection

On 31/01/2018 9:12 pm, Bastian Blank wrote: > On Wed, Jan 31, 2018 at 03:31:08PM -0500, Viktor Dukhovni wrote: >> Is "SwissSign Silver CA - G2" included in your "ca bundle"? > Also, is this server known to provide a client cert? > > Bastian > Not sure about 'provide', but the following shows it

Re: Achieving trusted TLS connection

On Wed, Jan 31, 2018 at 03:31:08PM -0500, Viktor Dukhovni wrote: > Is "SwissSign Silver CA - G2" included in your "ca bundle"? Also, is this server known to provide a client cert? Bastian -- There's another way to survive. Mutual trust -- and help. -- Kirk, "Day of the Dove",

Re: Achieving trusted TLS connection

> On Jan 31, 2018, at 2:46 PM, Danny Horne wrote: > > I didn't think achieving an inbound trusted TLS connection required > DANE, merely a trusted certificate (which was verifiable through my > trusted CA file. > > Maybe I misunderstood the documentation. I see, sorry, I

Re: Achieving trusted TLS connection

Thanks for the reply, I didn't think achieving an inbound trusted TLS connection required DANE, merely a trusted certificate (which was verifiable through my trusted CA file. Maybe I misunderstood the documentation

Re: Achieving trusted TLS connection

> On Jan 31, 2018, at 1:14 PM, Danny Horne wrote: > > I've read what Postfix documentation I can find on the subject, and I > don't understand why I'm seeing untrusted connections rather than > trusted. I'm using an account at mailbox.org for testing purposes, they > use