# certs

## Ronaldlees

Every once in a while I have to go down this rabbit hole, it seems.  There is another forum I visit, and one of the other member's avatars points to a https URL on a pic site - let's say it's https://xx227766.com/.../...some.jpg for the moment (even tho it's not). That in itself is no problem, except that Netsurf raises an alarm message about a bad cert on the avatar source, and clicking the reject button prevents the avatar from showing.  I did a cert check with a bunch of tools:

First, got the cert:

openssl s_client -port 443 -CApath /etc/ssl/certs -host xx227766.com (cut and paste cert into thesite.pem)

Then,

vfychain -a ./thesite.pem  (calls it a bad cert)

openssl s_client -port 443 -CApath /etc/ssl/certs -host xx227766.com (calls it a bad cert)

netsurf-gtk (calls it a bad cert)

curl https://xx227766.com (calls it a bad cert)

openssl s_client -showcerts -connect xx227766.com:443  (calls the one it downloaded separately a bad cert)

certutil -L -d .   (dutifully shows the COMODO root cert is present on system)

portage is up to date with ca-certifciates from 07/07/2017 and NSS is 3.34.1

Here's the question.  Firefox-52 shows the avatar, and issues no warning.  The question is why FF would not issue a warning when the library it uses (I'd guess this is true because vfychain is a NSS utility, and ldd shows that vfychain uses the nss library) - does show it as a bad cert.  I know that curl is using openssl, and netsurf is using curl, so most of the items really reflect the openssl opinion, and the vfychain speaks to the FF end of things. I'd think an alarm would be raised by the latter.

----------

## szatox

One thing is that some browsers have their internal root CA store and ignore setting in your system.

Another possible reason is a broken chain in the certificate. You know, your browser knows root CA, but the website's certificate has been signed with an intermediate CA. Website should provide that CA's certificate too, but some are misconfigured and don't do that. They can still be recognized as valid if your browser has internal intermediate CA cache (firefox does, curl does not) and you have visited another website providing this intermediate CA's certificate.

Finally, some browsers may simply freak out when a website embeds external content. It's a bit paranoid, but may be justified, though in this case it should complain before checking the certificate and word it in a clearer way. So the option no. 2 (a gaping hole in the chain of trust)  is the most likely one here.

----------

## Hu

As I understand it, Firefox is the odd one out here.  It's not clear from the description whether certutil rejects the certificate or even if it is expected to reject it (versus merely describe it).

Most browsers, including Firefox, allow the user not only to override the unrecognized certificate warning, but to choose never to be notified again about that problem.  Perhaps at some point you told Firefox not to bother you about that server, so now it remembers and silently permits it.  All the other tools, being unaware of this user override, warn.

----------

## Ronaldlees

 *szatox wrote:*   

> One thing is that some browsers have their internal root CA store and ignore setting in your system.
> 
> Another possible reason is a broken chain in the certificate. You know, your browser knows root CA, but the website's certificate has been signed with an intermediate CA. Website should provide that CA's certificate too, but some are misconfigured and don't do that. They can still be recognized as valid if your browser has internal intermediate CA cache (firefox does, curl does not) and you have visited another website providing this intermediate CA's certificate.
> 
> Finally, some browsers may simply freak out when a website embeds external content. It's a bit paranoid, but may be justified, though in this case it should complain before checking the certificate and word it in a clearer way. So the option no. 2 (a gaping hole in the chain of trust)  is the most likely one here.

 

Now, I'm getting a positive result from vfychain:

# Get cert for xx227766.com

openssl s_client -showcerts -connect xx227766.com:443 (this single cert is signed by intermediate, so paste the single cert into xx227766.pem)

# Get intermediate comodo cert from NSS db:

certutil -L -d . -n "COMODO RSA Domain Validation Secure Server CA" -a -o comodo-inter.pem

# Get root comodo cert from system file: 

cat COMODO_Certification_Authority.crt > comodo-root.pem 

# verify chain

vfychain -a comodo-root.pem -a comodo-inter.pem -a xx227766.pem

Chain is good!

So, at this point only the openssl side (openssl, curl, netsurf, et al) is calling the cert bad. 

Edit:

   Found the real problem: there was no comodo root cert in /etc/ssl/certs/ca-certificates.crt (used by openssl, curl, netsurf, etc).  Isn't that file derived from NSS on Gentoo?!!  I thought  it was.  Anyway, I just pasted the comodo root cert gotten from the COMODO_Certification_Authority.pem file into /etc/ssl/certs/ca-certificates.crt.  That left no intermediate cert still, as that was not provided by the www site. So, I pasted the intermediate cert from the NSS database into /etc/ssl/certs/ca-certificates.crt.  I assumed the intermediate cert was validated by FF before being cached.  Now it works, but obviously the site is misconfigured, and sends no intermediate.

----------

## Ronaldlees

 *Hu wrote:*   

> As I understand it, Firefox is the odd one out here.  It's not clear from the description whether certutil rejects the certificate or even if it is expected to reject it (versus merely describe it).
> 
> Most browsers, including Firefox, allow the user not only to override the unrecognized certificate warning, but to choose never to be notified again about that problem.  Perhaps at some point you told Firefox not to bother you about that server, so now it remembers and silently permits it.  All the other tools, being unaware of this user override, warn.

 

I never accept any certificates via an error dialog in any browser  :Smile: 

The site was misconfigured, as I've determined while going round-and-round for an excessive time (the rabbit hole which I avoid as much as possible).  It feels a little shaky to me to be doing all this sort of thing.  I guess it's the downside of using browsers that don't have all the bells and whistles (no intermediate cache), when they encounter misconfigured sites. I have one more question.  Are all of the certs displayed by the certutil utility cached? I.E, :

certutil -L -d ~/.mozilla/firefox/*default/

----------

## John R. Graham

 *Ronaldlees wrote:*   

> Found the real problem: there was no comodo root cert in /etc/ssl/certs/ca-certificates.crt (used by openssl, curl, netsurf, etc).  Isn't that file derived from NSS on Gentoo?!!  I thought  it was. ...

 

```
~ # equery belongs /etc/ssl/certs/ca-certificates.crt 

 * Searching for /etc/ssl/certs/ca-certificates.crt ... 

app-misc/ca-certificates-20161130.3.30.2 (/etc/ssl/certs/ca-certificates.crt)
```

- John

----------

## Ronaldlees

 *John R. Graham wrote:*   

>  *Ronaldlees wrote:*   Found the real problem: there was no comodo root cert in /etc/ssl/certs/ca-certificates.crt (used by openssl, curl, netsurf, etc).  Isn't that file derived from NSS on Gentoo?!!  I thought  it was. ... 
> 
> ```
> ~ # equery belongs /etc/ssl/certs/ca-certificates.crt 
> 
> ...

 

Hi John.  Yes, I saw that it's pretty old by default, but I used:

emerge =ca-certificates-20170717.3.34

Yet - maybe even that one needs to be looked at ...

----------

## John R. Graham

You seemed to be asking where that file came from; I was just trying to show you how to ask.   :Wink: 

But, while we're at it,

```
emerge =ca-certificates-20170717.3.34
```

pollutes your world file by explicitly asking for something that should normally only be brought in as a dependency. You should use --oneshot to prevent that. Use

```
emerge --deselect =ca-certificates-20170717.3.34
```

to clean up.

- John

----------

## Ronaldlees

 *John R. Graham wrote:*   

> You seemed to be asking where that file came from; I was just trying to show you how to ask.  
> 
> But, while we're at it,
> 
> ```
> ...

 

I'm a two-weeks-on-Gentoo guy, so I'm just guessing all over the place.  But, thanks John - appreciate the tip.  I probably did pollute something, because I reinstalled ca-certificates and now comodo root is there (but not the intermediate, of course).  At least things are starting to make sense, even if the details are ugly.

----------

