Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
certs
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Ronaldlees
n00b
n00b


Joined: 14 Dec 2017
Posts: 8

PostPosted: Thu Jan 11, 2018 10:57 pm    Post subject: certs Reply with quote

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.
_________________
I am the Umbrella Man
Back to top
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1717

PostPosted: Fri Jan 12, 2018 12:12 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13504

PostPosted: Fri Jan 12, 2018 3:39 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Ronaldlees
n00b
n00b


Joined: 14 Dec 2017
Posts: 8

PostPosted: Fri Jan 12, 2018 4:12 am    Post subject: Reply with quote

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.
_________________
I am the Umbrella Man
Back to top
View user's profile Send private message
Ronaldlees
n00b
n00b


Joined: 14 Dec 2017
Posts: 8

PostPosted: Fri Jan 12, 2018 3:55 pm    Post subject: Reply with quote

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 :-)

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/
_________________
I am the Umbrella Man
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10157
Location: Somewhere over Atlanta, Georgia

PostPosted: Fri Jan 12, 2018 4:17 pm    Post subject: Reply with quote

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. ...
Code:
~ # 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
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
Ronaldlees
n00b
n00b


Joined: 14 Dec 2017
Posts: 8

PostPosted: Fri Jan 12, 2018 4:28 pm    Post subject: Reply with quote

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. ...
Code:
~ # 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


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 ...
_________________
I am the Umbrella Man
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10157
Location: Somewhere over Atlanta, Georgia

PostPosted: Fri Jan 12, 2018 4:38 pm    Post subject: Reply with quote

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,
Code:
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
Code:
emerge --deselect =ca-certificates-20170717.3.34
to clean up.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
Ronaldlees
n00b
n00b


Joined: 14 Dec 2017
Posts: 8

PostPosted: Fri Jan 12, 2018 4:43 pm    Post subject: Reply with quote

John R. Graham wrote:
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,
Code:
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
Code:
emerge --deselect =ca-certificates-20170717.3.34
to clean up.

- John


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.
_________________
I am the Umbrella Man
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum