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.


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.


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

  • VM sits on IP 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.

  • @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. Apr 29, 2017 at 5: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 Apr 29, 2017 at 6:01
  • Triple check your /etc/hosts file, maybe?
    – Stephan
    Apr 29, 2017 at 6:59
  • thanks @Stephan, but yes an entry of 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 Apr 29, 2017 at 7: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 Apr 29, 2017 at 7:20

1 Answer 1


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:

distinguished_name = req_distinguished_name
req_extensions = v3_req

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

DNS.1 = kb.example.com
DNS.2 = helpdesk.example.org
DNS.3 = systems.example.net
IP.1 =
IP.2 =

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.

  • 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 Apr 29, 2017 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.