# ca_root_nss-3.27* issue



## brom (Oct 14, 2016)

Hello,

It seems bundle of CA is "broken" inside 3.27* version. 
After upgrade:

```
# fetch -o /dev/null https://yahoo.com
Certificate verification failed for /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
91353:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:980:
fetch: https://yahoo.com: Authentication error

# fetch -o /dev/null https://google.com
Certificate verification failed for /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
91357:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:980:
fetch: https://google.com: Authentication error
```
With file from 3.26:

```
# fetch -o /dev/null --ca-cert=/etc/ssl/cert_3.2.6.pem https://yahoo.com
fetch: https://yahoo.com: size of remote file is not known
/dev/null                                              443 kB 1635 kBps 00m01s

# fetch -o /dev/null --ca-cert=/etc/ssl/cert_3.2.6.pem https://google.com
fetch: https://google.com: size of remote file is not known
/dev/null                                               10 kB   36 MBps 00m00s
```


----------



## kpa (Oct 14, 2016)

Show us the output of `pkg query -e '%n=ca_root_nss' '%Ok %Ov'`.


----------



## brom (Oct 14, 2016)

Symlink is present physically.
And 

```
# pkg query -e '%n=ca_root_nss' '%Ok %Ov'
ETCSYMLINK on
```



kpa said:


> Show us the output pkg query -e '%n=ca_root_nss' '%Ok %Ov'


----------



## kpa (Oct 14, 2016)

I can't reproduce this on 11.0-RELEASE-p1. Version of my installed security/ca_root_nss is 3.27.1.


----------



## xtaz (Oct 14, 2016)

I've noticed that it will no longer validate the certificate from imap.gmail.com, so I disabled certificate validation to "fix" it. But yes, this worked on older versions of NSS.

I wondered if it was related to this: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.27_release_notes where it says that "The following CA certificates were *Removed*, one of which is O = Equifax, OU = Equifax Secure Certificate Authority which is what gmail uses.

I'm also using libressl. Not sure if that makes a difference. Symlink present etc. Worked on NSS 3.26.


----------



## brom (Oct 14, 2016)

This is 9.3-RELEASE-p43


----------



## xtaz (Oct 14, 2016)

11.0-STABLE in my case with the security/libressl-devel port. Pointing directly to the cert bundle doesn't help.


```
openssl s_client -connect google.com:443 -CAfile /usr/local/etc/ssl/cert.pem
...
verify error:num=20:unable to get local issuer certificate
```


----------



## SirDice (Oct 14, 2016)

Try removing /usr/local/etc/ssl/cert.pem and reinstalling security/ca_root_nss. Your /usr/local/etc/ssl/cert.pem may be old. Have a look at the file itself, the remarks at the top should show the version of the file. The "problem" with ports/packages is that they'll never overwrite a "configuration" file if it already exists.


----------



## xtaz (Oct 16, 2016)

The version is "##  Extracted from nss-3.27.1" in the file. So it is up to date.


----------



## xtaz (Oct 20, 2016)

I find it weird that nobody else seems to have complained about this. If I downgrade ca_root_nss to 3.26 then google sites work fine. Upgrade it to 3.27.1 again and they break. It appears to be because in 3.27.1 they have removed several 1024 bit SHA1 certificates including an Equifax one. https://www.ssllabs.com/ssltest/ana...72.217.5.110&hideResults=on&ignoreMismatch=on shows that this removed certificate is still used by google.

I guess this is actually an NSS/Google problem and nothing to do with the port, so probably nothing we can do about it.

Doing a diff of the two bundles:


```
< ##  Extracted from nss-3.26
---
> ##  Extracted from nss-3.27.1
...
<     Signature Algorithm: sha1WithRSAEncryption
<         Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
<         Validity
<             Not Before: Aug 22 16:41:51 1998 GMT
<             Not After : Aug 22 16:41:51 2018 GMT
<         Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
<         Subject Public Key Info:
<             Public Key Algorithm: rsaEncryption
<                 Public-Key: (1024 bit)
...
< ##  Number of certificates: 175
---
> ##  Number of certificates: 165
```

And running `openssl s_client -connect google.com:443 -CAfile /usr/local/etc/ssl/cert.pem`:


```
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Verify return code: 20 (unable to get local issuer certificate)
```


----------



## woodsb02 (Oct 23, 2016)

xtaz said:


> I find it weird that nobody else seems to have complained about this.



I am getting the same result when trying to verify the www.google.com certificate with LibreSSL 2.4.3 on FreeBSD 12-current r307773 with ca_root_nss 3.27.1.


----------



## brom (Oct 26, 2016)

This is not only google issue, it related to various sites. So this is "wide" issue I think.


----------



## woodsb02 (Nov 2, 2016)

It looks like this is resolved now - do you agree brom?


----------



## xtaz (Nov 2, 2016)

Definitely isn't resolved. Absolutely nothing has changed. Google still use an intermediate certificate which has been removed from the NSS CA bundle list in 3.27.1 as far as I can tell so it doesn't chain or validate.


----------



## SirDice (Nov 2, 2016)

It may not have anything to do with nss_root_ca. This is on an updated 10.3-RELEASE with ca_root_nss version 3.27.1:
Using the base OpenSSL:

```
> /usr/bin/openssl s_client -connect google.com:443 -CAfile /usr/local/etc/ssl/cert.pem
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
```
Certificate chain checks out.

Using LibreSSL:

```
> /usr/local/bin/openssl version
LibreSSL 2.4.3
> /usr/local/bin/openssl s_client -connect google.com:443 -CAfile /usr/local/etc/ssl/cert.pem
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
```


----------



## xtaz (Nov 2, 2016)

Oh that's interesting. That would certainly explain why some people say they don't see a problem. It must be a combination of LibreSSL and NSS then. As I mentioned before, if you downgrade the NSS port to 3.26 it validates fine with LibreSSL, but 3.27.1 it does that. I'm a bit stuck as to why though.........


----------



## SirDice (Nov 2, 2016)

It's also somewhat confusing if you have OpenSSL from ports or LibreSSL installed. In that case you have 2 openssl executables. One /usr/bin/openssl (the base OpenSSL) and /usr/local/bin/openssl (OpenSSL from ports or LibreSSL). Depending on the order of your PATH you may get one or the other.


----------



## xtaz (Nov 20, 2016)

FYI, this is relevant: https://github.com/libressl-portable/portable/issues/80 , looks like there is a fix in the next version of libressl.


----------

