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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .