Re: [Lynx-dev] SSLcerts config help

[Thorsten Glaser]

Stefan Caunter dixit:

>TG set up a bundle (in 2006 and it is still working, so running

Yes, it is, for me…

>will get you a reasonably recent cert bundle in shar format (the link
>to http://caunter.ca/ssl.certs.shar in README.sslcerts has been
>updated with the most recent archive).

… but you might wish to make note of src/etc/ssl.links.shar, which
creates symlinks of those certificates in the format OpenSSL 1.x
expects (the format of ssl.certs.shar is for OpenSSL 0.x and GnuTLS,
and it makes sense to have both available, both in /etc/ssl/certs/
or whereever the OS’ crypto library searches for them).

One more thing I didn’t remember yesterday in IRC:

Some servers ship certificates with signing chains as follows:


               ╔═════════════╗
               ║ Authority A ║
               ╚══════╤══════╝
                      │
               ╔══════╧══════╗
               ║ Authority B ║
               ╚══════╤══════╝
                      │
             ┌────────┴────────┐
             │ Intermediate CA │
             └────────┬────────┘
               ┌──────┴──────┐
               │ Server Cert │
               └─────────────┘

In this case, both CAs with double lines are (possible)
Root CA certificates; this is called cross-signing. The
situation is often used to introduce new roots not shipped
by browsers and other certificate bundles yet.

Now, the situation with some is that Authority A has a
1024-bit RSA key and Authority B has a 4096-bit RSA key,
and Authority B is sufficiently aged so that certificate
bundles (including mine) and browsers kick Authority A,
which itself stopped operation some time ago (due to it
being replaced by a 4096-bit RSA one, which may or may
not be Authority B), off.

SSL servers send a chain to the client consisting of their
own server certificate and all intermediates up to, but
not including, the final root certificate.

The problem here is that, even if you have Authority B
in the bundle, it’s not used, and it looks for Authority A,
which you don’t have in the bundle, because OpenSSL, in old
versions, insists on tracking the entire chain as-is. This
is because the version of Authority B you actually have in
the trust store is slightly different (self-signed instead
of signed by Authority A; everything else is the same though),
and so it still looks for A because the server sent a B that
says to look for A, which is kinda silly when you have B in
the root store and it’s a valid root certificate.

A workaround is to revert to r1.45 of ssl.certs.shar (and
r1.2 of ssl.links.shar) which still shipped some of those
old certificates (though it means you miss some newer ones
and some updates).

Another workaround is to patch OpenSSL as I did, backporting
a change that permits OpenSSL to use any certificate in the
local trust store (/etc/ssl/certs/) as trust root. This is
only somewhat wise because it can be used (was even written
to enable that) to trust non-CA certificates. That patch is at
https://www.mirbsd.org/cvs.cgi/src/lib/libssl/src/crypto/x509/x509_vfy.c
the delta between r1.5 and r1.6 (link [19]preferred in lynx).
Test case: https://www.benefind.de/index.php?org=1647 works
with this patch and r1.46 of ssl.certs.shar, and without it
and r1.45 of ssl.certs.shar but not r1.46.

OpenSSL upstream initially (the commented-out if-part in the
patch) enabled this only on application request; they later
wrote code that always checks all possible trust chains (i.e.
it checks both with A as root and with B as root) without
the part of being able to trust a not-root.

This is all AIUI, of course, but given what I maintain it
should be close enough to The Truth ☺

bye,
//mirabilos
-- 
18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the
same window anyway      18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of
telnet with automatic pong         18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D
18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy