Bug 202173

Comment 1 Peter Wemm 2015-08-09 10:11:49 UTC

Please install the ca_root_nss package and that will fix it.

ca_root_nss-3.19.3 - was installed before this PR created, ETCSYMLINK - ON.
libressl used instead openssl.

Comment 3 Peter Wemm 2015-08-19 19:37:54 UTC

I'm not sure what else to do.  You *have* the right certificate.

https://www.freebsd.org/doc/handbook/svn.html
the published fingerprint is:
E9:37:73:80:B5:32:1B:93:92:94:98:17:59:F0:FA:A2:5F:1E:DE:B9
and that's what your client is reporting.

Perhaps libressl isn't working with ca_root_nss?

You haven't even mentioned which svn client you are using.   svnlite from base? svn from ports?  svn on some other OS?  What versions?

And what happens if you use "https://svn.freebsd.org/base" in a browser? Does it validate for you there?

You have a local problem somewhere at your end, but you haven't given enough information to guess what it might be.

Some other ideas for you to help find your problem:

# ldd `which svn` | grep crypto
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x80139c000)
# strings /lib/libcrypto.so.7 | fgrep /etc
OPENSSLDIR: "/etc/ssl"
/etc/ssl/private
/etc/ssl
/etc/ssl/certs
/etc/ssl/cert.pem
# ls -l /etc/ssl/cert.pem 
lrwxr-xr-x  1 root  wheel  38 Aug 15 09:40 /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt
# ls -l /usr/local/share/certs/ca-root-nss.crt
-rw-r--r--  1 root  wheel  944269 Aug 15 09:40 /usr/local/share/certs/ca-root-nss.crt

svn from ports
libressl from ports

strings /usr/local/lib/libcrypto.so.35 | grep etc
...
OPENSSLDIR: "/usr/local/etc/ssl"
...
/usr/local/etc/ssl/private
/usr/local/etc/ssl
/usr/local/etc/ssl/certs
/usr/local/etc/ssl/cert.pem


# ls -l /etc/ssl/cert.pem
lrwxr-xr-x  1 root  wheel    38B Aug 15 03:00:32 2015 /etc/ssl/cert.pem@ -> /usr/local/share/certs/ca-root-nss.crt

# ls -l /usr/local/etc/ssl/cert.pem
-rw-r--r--  1 root  wheel   225K Aug 17 02:33:17 2015 /usr/local/etc/ssl/cert.pem

# ls -l /usr/local/etc/ssl/cert.pem.sample 
lrwxr-xr-x  1 root  wheel    38B Aug 15 03:00:32 2015 /usr/local/etc/ssl/cert.pem.sample@ -> /usr/local/share/certs/ca-root-nss.crt

# pkg which /usr/local/etc/ssl/cert.pem
/usr/local/etc/ssl/cert.pem was installed by package libressl-2.2.2

Im rename /usr/local/etc/ssl/cert.pem to _cert.pem
then create simlink
# ls -l /usr/local/etc/ssl/cert.pem.sample 
lrwxr-xr-x  1 root  wheel    38B Aug 15 03:00:32 2015 /usr/local/etc/ssl/cert.pem@ -> /usr/local/share/certs/ca-root-nss.crt

this fix problem.
What is correct way to fix?

Comment 6 Glen Barber 2015-08-20 18:32:37 UTC

Adding the security/libressl maintainer to CC list, since this looks like a problem with the port.

Comment 7 Peter Wemm 2015-08-20 20:18:39 UTC

When I you mentioned that libressl has its own certificate bundle I had a look.  Libressl's 225k bundle vs the standard 944k bundle means a lot were removed.  I discovered that libressl appear to not have added the new sha256 certificate roots to their bundle and keep relying on the antiquated sha1 roots.

If you look at the trust chains here:
https://www.ssllabs.com/ssltest/analyze.html?d=svn.freebsd.org

The second path was incomplete - certificate 3 required an extra download.  I would guess that either svn or libressl do not do downloads to complete the chain.

In any case, the sha256 chain that was "complete" does not appear to end in a certificate that libressl trusts.

The 4-step chain that ends in the legacy sha1 signature does appear to be trusted by libressl.

I made one change to the servers - I added the intermediate certificate from the modern sha256 certificate chain to the legacy sha1 root and it now should be complete.

This may fix svn with libressl without requiring ca_root_nss, but I have no desire to build/install it if it prefers legacy sha1 roots over sha256 roots.

Please try reverting the symlink change and let us know.

Comment 8 Vsevolod Stakhov 2015-08-20 21:54:02 UTC

There is no sense in using sha2 for root certificates and calling sha1 'ancient' in this case. For the root certificates, hash is merely an integrity control and not something that is used in digital signatures since we are already trusting this particular CA root certificate. Therefore, I'm not sure that we should have intermediate certs in the chain as their purpose is slightly different (and they are actually signed or cross-signed). And I'm not sure that including such a certificates is a good choice (perhaps, that's why LibreSSL developers have removed them from their persistent trusted storage).

Comment 9 Peter Wemm 2015-08-20 23:11:39 UTC

Well, since it seems I managed to touch some sensitive points, let me try again.

svn.freebsd.org's 4096 bit public key is signed by an intermediate:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2
        Validity
            Not Before: Jun 22 00:00:00 2015 GMT
            Not After : Jun 22 23:59:59 2016 GMT
        Subject: OU=Domain Control Validated, OU=Gandi Standard SSL, CN=svn.freebsd.org

That intermediate's 2048 bit public key is signed with another intermediate:
    Signature Algorithm: sha384WithRSAEncryption
        Issuer: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
        Validity
            Not Before: Sep 12 00:00:00 2014 GMT
            Not After : Sep 11 23:59:59 2024 GMT
        Subject: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2


That intermediate's 4096 bit public key is signed with:
    Signature Algorithm: sha384WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority

The mozilla/chrome/ie/safari/osx/ca_root_nss default bundles have both
 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
and
 C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
as recognized roots.

The problem the original reporter is having is that only the second one was recognized and that we were not providing the extra intermediate to reach it.  We were using the gandi-recommended intermediate bundle.

I've added an extra intermediate to extend the chain one more entry for libressl users.  libressl users will have to verify 4 deep, while everyone else only has to do 3 deep.  The non-libressl stacks have the USERTrust ECC/RSA certs in their root store, while libressl users have to be receive a copy over the network each time.

So, I'm sorry about the sha1 thing - it's misdirection.  The problem was that we were relying on a remote / extra download intermediate. Browsers do this, apparently svn and/or libressl don't do it.  Completing the server-downloaded chain should solve this as a longer path for libressl users.

Comment 10 Peter Wemm 2015-08-21 00:37:52 UTC

(In reply to rozhuk.im from comment #5)

Could you please check that it is fixed with your symlink change reverted?

Yes, fixed!