4

I am using Ubuntu 16.04 LTS and I am experiencing expired certificate issues (mainly with Google sites). I have followed the steps (without error) in Problem with certificates and this does not resolve the issue. Obviously I am unable to connect to any Google site to obtain assistance there and would appreciate any help. I have attached a screen shot of the Untrusted Certificates appearing in Chrome. I am getting these errors in firefox on my ubuntu box and my windows machines. I have also taken a look at Fake UserTrust.com Certificates in Chrome? but there did not appear a resolution implied. Thank you in advance. Apologies for forgetting the attachment.

Screen shoot of chrome untrusted certificates

feeks
  • 41

2 Answers2

2

Your question is interesting and helpful!

My initial response cost me a few points but oh well. I'm learning valuable knowledge too.

You can update the installed certificates Authority (CA) certs as follows

sudo update-ca-certificates

You can verify if you are resolving to the right address by typing:

dig (or nslookup or ping) google.com

whois the.address.dig.returns

A site with a bogus cert spoofing google will not have an IP address that is in google.com's assigned netblock.

If you can ping a DNS entry that resolves to a google-assigned IP your browser should be able to view pages at the same address.

To eliminate the browser as an issue, you can always try

lynx https://google.com

If this fails, you'll know it's an ssl issue if the following works

lynx http://google.com

You may have to install lynx with 

sudo apt-get install lynx

You can look at a servers current ssl certificates with the command

openssl s_client -showcerts -servername google.com -connect google.com:443 |tee google.crt

QUIT

You can view the certificate details with this command

openssl x509 -inform PEM -in google.crt -text -out certdata

For test purposes I wrote the cert file to my home directory.

If the above openssl s_client command doesn't work, you can at least check to see if the web site is blocking your access to it. You won't be able to do anything but if you get a "Connected to google.com" response for the following command you'll know that packet blocking is not in play.

telnet google.com 443

On the browser side (using Firefox in my example) 

edit-> preferences-> certificates-> view certificates-> servers-> add exception

In the Location window type

https://google.com

and press Get Certificate

Should return with a Valid certificate message.

Press View to look at the certificate

jones0610
  • 2,157
  • 1
    -1 You obviously misunderstood the point of having those bogus certificates present and marked "untrusted". It is so that the browser does not trust it, no matter what the expiration date is. – muru Jun 14 '17 at 03:35
  • Wouldn't be the first time I didn't understand something. But wouldn't a correct and current cert over-ride an expired (or missing) cert anyway? I gave the OP a +1 on his question because I don't see an https connection to google.com adding a correct, valid, current cert to the browser's list. In fact, all of the certs in the certificate manager are flagged as bogus. – jones0610 Jun 14 '17 at 03:44
  • 1
    Bogus certificates are used by fake sites to misrepresent themselves as real ones. Having correct and current certs don't help with that - you need to mark those bogus ones as bogus. Connecting to an HTTPS site should not add a certificate to anything. If all of your certificates are marked as bogus, you're looking at the wrong thing. – muru Jun 14 '17 at 04:01
  • @muru I appreciate the chastisement (truly) and even the loss of rep points. Did a lot of research and testing, learned a lot.... which is my primary reason for being here. I still may not have it down 100% but I know more now than I did when I first looked at this thread. Much appreciated. – jones0610 Jun 14 '17 at 05:28
  • @jones0610/@muru - I went through your checklist with the only failures being lynx https://google.com (unable to make secure connection to remote host).
    openssl x509 returned (unable to load certificate 140633892107928:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE);
    dig returned NetRange: 216.58.192.0 - 216.58.223.255 CIDR: 216.58.192.0/19; whois returned what appears to me to be relevant google data
    I look forward to any feedback that can be provided.     – feeks Jun 14 '17 at 06:31
  • Is https://google.com the only ssl URL that doesn't work? You alluded that there were others. Instead of piping the output of openssl s_client to a file, you can drop |tee google.com and print it to the screen. If what you see is a valid cert then you are at least able to connect to google's ssl port. – jones0610 Jun 14 '17 at 06:41
  • I'm still unclear about the need for bogus certificates. Since the bogus certificate scammers were using has obviously been revoked, wouldn't the browser refuse to connect to the site? This is why I asked the OP to verify that google.com resolves to an actual Google IP address. If DNS is sending him to a fake site with a revoked cert wouldn't he get exactly the failure he's seeing? – jones0610 Jun 14 '17 at 07:05
  • @jones0610 I have failed to Get Certificate from https://google.com returns an "unable to return identification status for this site " error. The other sites are as per the image attached to the original question – feeks Jun 14 '17 at 07:06
  • Not to be a nag but if you do a ping google.com what IP does it ping to? – jones0610 Jun 14 '17 at 07:11
  • @jones0610 -- ping to google.com returns 216.58.203.110 this is also on my windows box – feeks Jun 14 '17 at 07:12
  • And openssl s_client -showcerts -servername google.com -connect google.com:443 |tee google.crt did or did not download a certificate? If not, something on the google end may be blovking port 443 connections from your IP. Like if you are on a VPN that uses servers that are routinely blacklisted. – jones0610 Jun 14 '17 at 07:19
  • @jones0610 -- I am not using a VPN Ouput from the the openssl comes back with 140001952372376:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794: CONNECTED(00000003) no peer certificate available No client certificate CA names sent SSL handshake has read 7 bytes and written 324 bytes New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported – feeks Jun 14 '17 at 07:32
  • Ok I have revisited and it would appear that openssl s_client only had problems with returning to certifications those being Global Trustee http://www.usertrust.com and mail.google.com. When viewing the certificate details also points to http://www.usertrust.com all the other untrusted certificates I have been able to obtain .crt for. Still going through the validity of what is actually in the certificates. Will update! – feeks Jun 15 '17 at 03:07
0

Thank you for the assistance. I have been able to gain a solution by taking a broader view. Given that the issue was affecting all devices behind my router I began examining here and found the culprit. I have a Draytek router which had recently been firmware update. The issue was that I was blocking a WED HD Google service, apparently under the updated firmware it block more than WEB HD. I will be following up with Draytek to obtain further clarification. For community benefit the following is the service block details:- Google Service 1.11.4865.2530 To block Gmail and Google Drive. If user has login, it can not be blocked.

feeks
  • 41