Achieving trusted TLS connection

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Achieving trusted TLS connection

Danny Horne
Hi all,

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 DNSSEC / DANE for there server (as do I), and I see a verified
connection when sending email to their server, but returned connections
are untrusted.

This is what's logged when TLS logging is set to 2 -

Jan 31 17:53:31 indium postfix/smtpd[30307]: setting up TLS connection
from mx1.mailbox.org[80.241.60.212]
Jan 31 17:53:31 indium postfix/smtpd[30307]:
mx1.mailbox.org[80.241.60.212]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL"
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
client hello
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
server hello
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
certificate
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
key exchange
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
certificate request
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
server done
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
server done
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
client certificate
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
client key exchange
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
certificate verify
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
change cipher spec
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS read
finished
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
session ticket
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
change cipher spec
Jan 31 17:53:31 indium postfix/smtpd[30307]: SSL_accept:SSLv3/TLS write
finished
Jan 31 17:53:31 indium postfix/smtpd[30307]: Untrusted TLS connection
established from mx1.mailbox.org[80.241.60.212]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

This is the relevant part of main.cf -

smtpd_use_tls = yes
smtpd_tls_key_file  = /etc/pki/tls/private/mail.trisect.uk.key
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.trisect.uk.crt
smtpd_tls_CApath = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_ccert_verifydepth = 2
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = no
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s

As far as I can tell the CA certificate used by mailbox.org is included
in ca-bundle.trust.crt

What have I missed (if anything)?

Thanks for looking

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni


> On Jan 31, 2018, at 1:14 PM, Danny Horne <[hidden email]> 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 DNSSEC / DANE for there server (as do I), and I see a verified
> connection when sending email to their server, but returned connections
> are untrusted.
>
> This is what's logged when TLS logging is set to 2 -

TLS log level 1 is almost always enough.  More logging generally just
makes it harder to see the key information amidst all the low-level
noise.

> Jan 31 17:53:31 indium postfix/smtpd[30307]: Untrusted TLS connection
> established from mx1.mailbox.org[80.241.60.212]: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

It is exactly what's expected. DANE TLS is used by clients to authenticate
servers.  There is no standard (I did not make progress on the draft
quickly enough) to use DANE to authenticate TLS clients to servers.

The server would need to know when and where to search for the client's
TLSA records.  This would perhaps require a new SMTP command so that the
server configures its TLS engine to ask for client certificates and would
look up the client's TLSA records at something like:

        _smtp-client.<helo-name-fqdn> IN TLSA ?

or a just-in-time TLS extension in the client TLS HELLO, that would
cause the server to do the same via a suitable TLS extension callback.

Even if this were all done, what would you do differently with clients
that did authenticate their HELO name (or some name sent in the TLS
extension)?

If there is a sufficiently well-motivated use-case for using DANE for
TLS client auth, I could resume work with Shumon Huque on the DANE
client auth draft, and add support for this in Postfix and OpenSSL,
but presently this does not seem a high priority.  It is not clear
what real benefit such client authentication would bring.

Perhaps once DANE authentication of servers is more common, we can
look at extending DANE to cover clients, but for now the first step
is convincing enough servers to publish TLSA records.

Presently, I am tracking 5.2 million DNSSEC domains of which 177
thousand have TLSA records for at least all their primary MX hosts,
with 176 thousand of those having TLSA records for all MX hosts.

While we have some good progress with early adopters, we still
have a long way to go.  I'll be giving a talk on DANE adoption
at ICANN61 in March.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
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
Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni


> On Jan 31, 2018, at 2:46 PM, Danny Horne <[hidden email]> 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 thought you were looking for DANE auth.  For
"trusted" client connections you'll need a suitable CApath
that includes the relevant trust-anchors and any intermediate
CAs that the sending client might have left out in error.

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
a "CAfile", but I very much recommend that you use CApath instead.  Point
your CApath at the directory with all the certs, that "hashed" via
"c_rehash" or similar.  If running smtpd(8) chrooted, make sure there's
a copy of the CApath directory inside the jail.

When mx1.mailbox.org is the receiving MTA, its certificate chain is:

  mx1.mailbox.org[80.241.60.212]: pass: TLSA match: depth = 0, name = *.mailbox.org
    TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
    name = *.mailbox.org
    name = mailbox.org
    depth = 0
      Issuer CommonName = SwissSign Server Silver CA 2014 - G22
      Issuer Organization = SwissSign AG
      notBefore = 2014-12-04T12:05:04Z
      notAfter = 2019-12-04T12:05:04Z
      Subject CommonName = *.mailbox.org
      pkey sha256 [matched] <- 3 1 1 4758af6f02dfb5dc8795fa402e77a8a0486af5e85d2ca60c294476aadc40b220
    depth = 1
      Issuer CommonName = SwissSign Silver CA - G2
      Issuer Organization = SwissSign AG
      notBefore = 2014-09-19T20:36:43Z
      notAfter = 2029-09-15T20:36:43Z
      Subject CommonName = SwissSign Server Silver CA 2014 - G22
      Subject Organization = SwissSign AG
      pkey sha256 [nomatch] <- 2 1 1 989c1c480d561396df0ac439a3bf70182bdab2fc1d56cce7665a91d47dd83dd2
    depth = 2
      Issuer CommonName = SwissSign Silver CA - G2
      Issuer Organization = SwissSign AG
      notBefore = 2006-10-25T08:32:46Z
      notAfter = 2036-10-25T08:32:46Z
      Subject CommonName = SwissSign Silver CA - G2
      Subject Organization = SwissSign AG
      pkey sha256 [nomatch] <- 2 1 1 9318226f8c83afe47f5f47c24f59ce12dba8c73b181bee6b2ea1f40a06bc1869


Is "SwissSign Silver CA - G2" included in your "ca bundle"?

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Bastian Blank-3
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", stardate unknown
Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
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 does use a
certificate included in my CA file

openssl s_client -showcerts -starttls smtp -connect mx1.mailbox.org:25

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni
In reply to this post by Bastian Blank-3


> On Jan 31, 2018, at 4:12 PM, Bastian Blank <bastian+postfix-users=[hidden email]> 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?

If it had not, the log message would have said "Anonymous", rather than "Untrusted".

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
In reply to this post by Viktor Dukhovni
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
> a "CAfile", but I very much recommend that you use CApath instead.  Point
> your CApath at the directory with all the certs, that "hashed" via
> "c_rehash" or similar.  If running smtpd(8) chrooted, make sure there's
> a copy of the CApath directory inside the jail.

I've changed smtpd_tls_CApath back to pointing at the directory.  Not
sure what you mean by "hashed" via "c_rehash"
>
> Is "SwissSign Silver CA - G2" included in your "ca bundle"?
>
Yes it is.  Is it possible that Postfix can't read that file for some
reason?

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni


> On Feb 1, 2018, at 10:44 AM, Danny Horne <[hidden email]> 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
>> a "CAfile", but I very much recommend that you use CApath instead.  Point
>> your CApath at the directory with all the certs, that "hashed" via
>> "c_rehash" or similar.  If running smtpd(8) chrooted, make sure there's
>> a copy of the CApath directory inside the jail.
>
> I've changed smtpd_tls_CApath back to pointing at the directory.  Not
> sure what you mean by "hashed" via "c_rehash"

Well, that's the critical part of using CApath, the directory needs to
contain a separate file for each trusted CA certificate and also be
"hashed" (indexed if you like) by the OpenSSL c_rehash program or
equivalent.  Some OS distributions do this for you automatically, as
part of updating the package that delivers the CA bundle.

You can tell when this is done because the directory will contain a
bunch of hexadecimal symlinks ending in .0 and increasingly less
frequently also .1, .2, ...  For example:

        cd8c0d63.0 -> fnmt-rcm.pem

In your case the hashed directory could any of:

   /etc/pki/ca-trust/extracted/openssl/
   /etc/pki/ca-trust/extracted
   /etc/pki/ca-trust
   /etc/pki

or even some other directory that uses the above as raw sources to make
links to.  If the OpenSSL library on your system is built to expect to
find certificates in the same place where they are delivered by the
certificate bundle package, then you can run:

  openssl version -d

which outputs something like:

   $ openssl version -d
   OPENSSLDIR: "/etc/ssl"

from which you can deduce that the built-in CAfile and CApath are:

        CAfile: /etc/ssl/cert.pem
        CApath: /etc/ssl/certs/

Adjust accordingly and look for lots of hexadecimal symlinks to
various <someca>.pem files.

>> Is "SwissSign Silver CA - G2" included in your "ca bundle"?
>>
> Yes it is.  Is it possible that Postfix can't read that file for some
> reason?

Strictly speaking, that'd be the OpenSSL library, called by the Postfix
smtpd(8) server.  And that problem could happen if you're running it
from a chroot jail, but first figure out whether you have a suitably
prepared CApath directory anywhere...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Bill Cole-3
In reply to this post by Danny Horne
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 name is
derived from a cryptographic hash of the "Subject" of the certificate
file to which it points. This is to support rapid identification of
trusted certificates cited as the "Issuer" of a certificate being
verified. If your OpenSSL is properly installed, you can get all the
details from 'man c_rehash' and if not, you can see the man page for
v1.0.2 at https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
In reply to this post by Viktor Dukhovni
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 tls]#
[root@indium tls]# ls -al /etc/pki/tls
total 12
drwxr-xr-x. 5 root root    81 Jan 24 16:41 .
drwxr-xr-x. 9 root root   103 Jan 26 20:18 ..
lrwxrwxrwx. 1 root root    49 Nov 27 21:00 cert.pem ->
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
drwxr-xr-x. 2 root root    97 Dec 21 17:31 certs
drwxr-xr-x. 2 root root     6 Nov  6 08:24 misc
-rw-r--r--. 1 root root 10841 Nov  6 08:20 openssl.cnf
drwxr-xr-x. 2 root root    60 Dec 21 17:32 private
[root@indium tls]#
[root@indium tls]# ls -al /etc/pki/ca-trust/extracted/pem
total 396
drwxr-xr-x. 2 root root    101 Dec 18 15:19 .
drwxr-xr-x. 5 root root     58 Dec 18 15:19 ..
-r--r--r--. 1 root root 179176 Dec 18 15:19 email-ca-bundle.pem
-r--r--r--. 1 root root      0 Dec 18 15:19 objsign-ca-bundle.pem
-rw-r--r--. 1 root root    898 Nov 27 20:58 README
-r--r--r--. 1 root root 219895 Dec 18 15:19 tls-ca-bundle.pem


Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni
In reply to this post by Bill Cole-3


> On Feb 1, 2018, at 11:43 AM, Bill Cole <[hidden email]> 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" of the certificate file to which it points. This is to support rapid identification of trusted certificates cited as the "Issuer" of a certificate being verified. If your OpenSSL is properly installed, you can get all the details from 'man c_rehash' and if not, you can see the man page for v1.0.2 at https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html.

Good clarification, thanks.  I just want to emphasize that
the "directory full of certificate files" needs to have one
certificate per file, as only the first certificate in each
file is processed by c_rehash.  There's not much point in
using CApath if all the certificates are in the same file,
so that's not supported.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni
In reply to this post by Danny Horne


> On Feb 1, 2018, at 11:45 AM, Danny Horne <[hidden email]> wrote:
>
> # openssl version -d
> OPENSSLDIR: "/etc/pki/tls"
>
> # ls -al /etc/pki/tls
> lrwxrwxrwx. 1 root root    49 Nov 27 21:00 cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
> drwxr-xr-x. 2 root root    97 Dec 21 17:31 certs
> drwxr-xr-x. 2 root root     6 Nov  6 08:24 misc
> -rw-r--r--. 1 root root 10841 Nov  6 08:20 openssl.cnf

Here we see that /etc/pki/tls is not only reported by
"openssl version -d", but also has a "cert.pem" file,
a "certs" sub-directory, and an openssl.cnf file.

This matches the layout expected by OpenSSL.  Given this,
I'd expect to find the hashed symlinks in:

        /etc/pki/tls/certs

Look there, and if all is as expected, your CApath would be:

  smtpd_tls_CApath = /etc/pki/tls/certs.

All this to get client certs to show as "Trusted", perhaps it
would have been easier to just not bother requesting client certs :-)

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 WebPKI trust-anchors (root CAs) DO NOT make the make the
mistake of also using "permit_tls_all_clientcerts", lest your server
become an open relay for every man and his dog who can get a Let's
Encrypt certificate...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
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 WebPKI trust-anchors (root CAs) DO NOT make the make the
> mistake of also using "permit_tls_all_clientcerts", lest your server
> become an open relay for every man and his dog who can get a Let's
> Encrypt certificate...
>
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

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
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
actually 'fixed' anything, I've learnt something new today
Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Bill Cole-3
In reply to this post by Viktor Dukhovni
On 1 Feb 2018, at 11:46, Viktor Dukhovni wrote:

>> On Feb 1, 2018, at 11:43 AM, Bill Cole
>> <[hidden email]> 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" of the certificate
>> file to which it points. This is to support rapid identification of
>> trusted certificates cited as the "Issuer" of a certificate being
>> verified. If your OpenSSL is properly installed, you can get all the
>> details from 'man c_rehash' and if not, you can see the man page for
>> v1.0.2 at https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html.
>
> Good clarification, thanks.  I just want to emphasize that
> the "directory full of certificate files" needs to have one
> certificate per file, as only the first certificate in each
> file is processed by c_rehash.  There's not much point in
> using CApath if all the certificates are in the same file,
> so that's not supported.

Yes, that's an important point.

If one has a bundle of certs in one file, one can do something like this
to split them into single-cert files (assuming you have GNU csplit):

csplit  -f ca-cert -b '.%03d.pem' curl-ca-bundle.crt '/END
CERTIFICATE/+1' {*}
Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni
In reply to this post by Danny Horne


> On Feb 1, 2018, at 12:10 PM, Danny Horne <[hidden email]> 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 WebPKI trust-anchors (root CAs) DO NOT make the make the
>> mistake of also using "permit_tls_all_clientcerts", lest your server
>> become an open relay for every man and his dog who can get a Let's
>> Encrypt certificate...
>>
> 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

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 = /etc/pki/tls/certs

which should work if the above directory has the expected symlinks.
Otherwise, you could run "c_rehash" to make it so.  That'll save
each smtpd(8) process the (probably small) cost of loading all the
CAs at startup.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
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 = /etc/pki/tls/certs
>
> which should work if the above directory has the expected symlinks.
> Otherwise, you could run "c_rehash" to make it so.  That'll save
> each smtpd(8) process the (probably small) cost of loading all the
> CAs at startup.
>
smtpd_tls_CApath is already set to that directory, and all files are
bundles, including many cacerts in the one file.  Bill Cole posted a
means of separating these, I might have a go at that later (can't find
c_rehash anywhere but do have csplit available)

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Viktor Dukhovni


> On Feb 1, 2018, at 1:26 PM, Danny Horne <[hidden email]> 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

Perhaps your O/S distribution left these to some package you did
not yet install.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Achieving trusted TLS connection

Danny Horne
On 01/02/2018 6:40 pm, Viktor Dukhovni wrote:

>
>> On Feb 1, 2018, at 1:26 PM, Danny Horne <[hidden email]> 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
>
> Perhaps your O/S distribution left these to some package you did
> not yet install.
>
Possibly, do I understand right that I'm going to have to separate all
cacerts from the bundle files before using rehash?
12