7

Google chromes update to version 58 started invalidating my self signed certificates a few days ago. It was complaining about missing subjectAltNames. I did some research and tried a couple of suggestions (which wouldn't work) but then found this post, the only one that I could get working.

Or did I?

Yay chrome is now accepting my newly generated and imported certificates and I was on my way,

until, I hit a page in my PHP web app that requires loading data from another micro web-service on the same dev machine.

stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:

I have been googling and tinkering with this for about 4 hours now and just cannot get my head around it.

Question

Why is chrome accepting my certificate. HOWEVER tools like curl, openssl s_client all giving me unable to verify the first certificate or invalid certificate? I have tried passing the certificate as a parameter and still apparently invalid.

Debugging with curl and openssl passing the certificate file as a parameter continues to give me this error

SSL certificate verify result: unable to get local issuer certificate (20),

I think Im gonna be completely bald by the end of the day.

Notes

  • The virtual machine is my local development environment so I do have multiple domains with their own cert and keys

  • VM sits on IP 192.168.33.10. meaning chrome is not accessing localhost. However curl and openssl s_clinet are trying to access locahost

  • Server is a VM running ubuntu 14.04

  • Installed self signed certificate on host machine with MMC (Microsofts management console)

  • Error is definitely coming from the client class trying to access a web-service.

  • I have tried passing the certificate as a parameter and still apparently invalid.

  • I am fully aware I can set verify peer to false or pass --insecure to the request but I don't learn anything from that.

  • SSL-Session: Protocol : TLSv1.2

  • ran sudo dpkg-reconfigure ca-certificates to update certs

  • have run sudo update_ca_ccertificates

  • I have reached frustration level 9000

Revert update

I regenerated a new certificate with v3 extension turned off and Back to chrome telling me subjectAltName is missing but curl is working. I need to work out how to genrate certs that both curl and chrome will accept.

Community
  • 1
Jason Joslin
  • 191
  • 1
  • 7
  • @garethTheRed I thought I had done that but I have just outputted my cert and `localhost` is not under the alt names. Let me try that and ill let you know how I get on. – Jason Joslin Apr 29 '17 at 05:08
  • @garethTheRed still did not work. Does prove that google is authenticating the certificates though. After the update chrome gave the invalid cert error and then once I reinstalled the newly generated one it started working again (in chrome only). Even when I pass the cacert file to curl with the --cacert flag i get `curl: (60) SSL certificate problem: unable to get local issuer certificate` So I dont believe its a cacert location issue – Jason Joslin Apr 29 '17 at 06:01
  • Triple check your /etc/hosts file, maybe? – Stephan Apr 29 '17 at 06:59
  • thanks @Stephan, but yes an entry of `127.0.0.1 my.domain.dev` is indeed present in the hosts file. anything else in that file required? when i add -showcerts param to my openssl request i get the expected certificate back. but for whatever reason it cant get issuer.. when its clearly there when you do an `openssl x5... --text` – Jason Joslin Apr 29 '17 at 07:01
  • @garethTheRed Yeah as I said I installed it with MMC. I have been passing the crt with the `--cacert` argument and its still saying it cannot get the issuer. I cant see how it could be an installation(adding to trust store) issue if im passing the crt directly? And if its a certificate issue howcome chrome can handle it fine and I can output the content correctly into text. so strange. I might have to set up another VM with same SSL signing method and see if it is replicate-able – Jason Joslin Apr 29 '17 at 07:20
  • Actually if i revert back to the old certificates and setup i had before adding subjectAltName and its working fine then it must be the way im generating the certificates – Jason Joslin Apr 29 '17 at 07:23
  • gives me return code: 21 (unable to verify the first certificate). i only set up the ssls for my virtual hosts not default/localhost/127.0.0.1. Do you think that could be the issue? – Jason Joslin Apr 29 '17 at 07:25
  • @garethTheRed i usually use the base64 but i have tried converting to DER to no avail. Ive tried both and they both could be decoded fine. just wont verify – Jason Joslin Apr 29 '17 at 07:27
  • @garethTheRed i have update my question with the update after re-generating the old certificates. Curl verifies successfully but chrome is complaining about missing `subjectAltName` again. I need to find out how i can sign subjectAltName without upsetting curl? – Jason Joslin Apr 29 '17 at 08:57
  • When using `openssl s_client` you should probably use the `-servername` parameter with the correct name, so that SNI works correctly otherwise the webserver may give you back a certificate for another host that the one you wanted to reach. – Patrick Mevzek Apr 30 '17 at 17:57
  • Thanks for your comment @PatrickMevzek . yes in my hours of debugging and research I came across that as well. You are right. i kept getting the wrong `cert` returned when i was using openssl until I found out about `SNI`. It turned out in the end I had not followed the tutorial correctly and had added additional parameters that were not required, google chrome must have known how to manage them or ignore the extra params – Jason Joslin Apr 30 '17 at 22:59

1 Answers1

2

Found a clearer tutorial that had a much simpler openssl.conf. In my original attempts to add SANs I must have un-commented extra lines in the conf that were adding extra info to the certs causing conflicts. Followed this template and my certificate is working all round:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = MN
localityName = Locality Name (eg, city)
localityName_default = Minneapolis
organizationalUnitName  = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Domain Control Validated
commonName = Internet Widgits Ltd
commonName_max  = 64

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = kb.example.com
DNS.2 = helpdesk.example.org
DNS.3 = systems.example.net
IP.1 = 192.168.1.1
IP.2 = 192.168.69.14

Thanks for your comments @garethTheRed. Your comments helped me re-think my approach to debugging this issue.

Even starting a post here helps me lay out what I've tried and helps the brain think up more possible solutions.

Jason Joslin
  • 191
  • 1
  • 7
  • This is my answer and it has resolved my question. SF doesn't let me mark it as correct until after 2 days. In fact its probably a duplicate question and being deleted could be the better option. Although ive never heard of someone have there certificate verifying by one client and not another – Jason Joslin Apr 29 '17 at 09:42