I am having the same issue as this ticket but it has not resolved over the past 5 days, so unlike this user I am not sure if it's a DNS issue or not. I am posting my version of the question since the answer to the other was "it resolved it's self" (which is not happening in my case).
Heroku: SSL Endpoint - subjectAltName does not match www.mydomain.com
I get this:
> heroku certs
Endpoint Common Name(s) Expires Trusted
------------------------ ---------------------------------- -------------------- -------
<xxx>.herokussl.com www.mysite.com, mysite.com True
So it seems like the cert is looking at the right site.
Like the other user I ran this and it's telling me the site is wrong.
> curl -kvI https://www.mysite.com
* About to connect() to www.mysite.com port xxx (#0)
* Trying ...
* connected
* Connected to www.mysite.com (...) port xxx (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Heroku, Inc.; CN=*.herokuapp.com
* start date: 2011-04-11 00:00:00 GMT
* expire date: 2014-04-15 12:00:00 GMT
* subjectAltName does not match www.mysite.com
Also, wanted to add, that if I go to https://.herokussl.com (from the endpoint), I get an error of "Heroku | No such app".
What I don't understand is how Heroku' SSL setup works exactly and there seem to be a lot of new moving pieces.
It looks to me that it's not picking up my certificate when it does the handshake and is picking up Heroku's and not my cert. Is this a correct read of the output?
What does the herokussl.com site do?
Thanks,
Renderbox
You will need to configure your DNS in your DNS zone file to the ssl-endpoint that heroku provides you with, something like tokyo-2121.herokussl.com rather than the generic Heroku endpoint like proxy.herokuapp.com.
Reference: Heroku SSL-Endpoint Documentation [link]
Related
The question seems to be asked before:
OpenSSL Verify return code: 20 (unable to get local issuer certificate). However the difference is that it is about a local issuer certificate. Besides, the answers are not for a Windows computer.
Problem description
On a windows computer, I've got a program that tries to contact a secure server. The security is with certificates on both sides.
Problem: I can't contact it, so I tried to find out if the certificates are correctly installed
Searches, a.o. here on stack overflow, indicated that a good method to find problems would be to use OpenSsl for this, even though I'm running a windows computer.
As an example to check if all certificates for a connection are correctly installed, I was advised to check the connection with google.com:
openssl.exe s_client -connect google.com:443
(My browsers have no problems connecting to this server)
The first lines of the response are
CONNECTED(00000184)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
...
And further down the same error twice:
Verification error: unable to get local issuer certificate
Verify return code: 20 (unable to get local issuer certificate)
Alas the OpenSSL documentation about s_client isn't very informative about these errors.
So what does it mean? Am I missing some certificates to communicate with google.com, or am I using the incorrect program for this?
Of course google.com is just an example. I chose this, so I could check if reported problems are because of certificate problems, or because of the command I use.
For my actual server that I try to contact, I have the proper certificates (up to the root) as .CER files. The root certificate is in the winstore.
Patrick Mevzek pointed me towards the proper answer (Thanks Patrick!). Because some investigation was needed, I decided to write it down as a complete answer.
I'm working in Windows Server 2012. Newer versions will probably work similarly. To test the certificates and the communication I use:
openssl for windows. Find a compiled version here
curl for window here
Files:
So I am a Client of a Server. There is a two-way secure certification: via very secure methods we have the following files:
A Root certificate that can be trusted: Root.Pem
A chain of untrusted certificates issued by the Root certificate: A.Pem, B.Pem, C.Pem
A private key file MyPrivate.key and a trusted certificate issued by C.Pemto ensure my identity: MyCertificate.pem
If needed, Convert certificate file to PEM format
If the certificates are not in PEM format, we need to convert them first. To check if they are in PEM, open them in a text editor. A PEM file looks like:
-----BEGIN CERTIFICATE-----
MIIFyjCCA7KgAwIBAgIEAJiWjDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJO
...
-----END CERTIFICATE-----
If it is not, we can use openSSL to convert the file:
openssl.exe x509 -inform DER -in myCertificate.cer -out myCertificate.Pem
inform: the format of the input file: DER / NET / PEM (well, if already PEM you won't have to convert)
in / out: the input file, the output file
Verify the certificate chain
For extra security, I verified every certificate separately. It is probably also safe to do this in one step.
Check validity of the root certificate. For instance by checking the fingerprint with a published fingerprint.
Check validity of the untrusted certificates
(1) Is A.pem issued by Root.Pem?
openssl.exe verify -show_chain -CAfile root.pem A.pem
Parameter -CAfile contains the trusted certificate. The last file is the file that contains the certificate to be verified.
Reply should be similar to:
A.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=1: C = NL, ..., CN = <some text describing the trusted root certificate>
(2) Is B.Pem issued by the trusted A.Pem?
Now that A.pem can be trusted, we can check B.Pem. For this we mention the intermediate certificate A.Pem as untrusted as advised in this answer
openssl.exe verify -show_chain -CAfile root.pem -untrusted A.pem B.pem
Reply:
B.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing certificate B> (untrusted)
depth=1: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=2: C = NL, ..., CN = <some text describing the trusted root certificate>
(3) Can we trust the rest of the certificate chain?
So now B can be trusted. To continue checking the chain, concatenate the untrusted CA-files into one untrusted.pem file. Do not add MyCertificate.Pem
-----BEGIN CERTIFICATE-----
MIIGNjCCBB6gAwIBA...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
jCCBB6gAwIBA34F..
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
dZBo31cAYsByRL...
-----END CERTIFICATE-----
And the command:
openssl.exe verify -show_chain -CAfile root.pem -untrusted untrusted.pem myCertificate.pem
Reply:
MyCertificate.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing MyCertificate> (untrusted)
depth=1: C = NL, ..., CN = <some text describing certificate C> (untrusted)
depth=2: C = NL, ..., CN = <some text describing certificate B> (untrusted)
depth=3: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=4: C = NL, ..., CN = <some text describing the trusted root certificate>
I guess maybe all those intermediate steps were not necessary to check the validity.
Check Connection
Now that the certificate chain is trusted, we can use OpenSsl to check the connection.
Concatenate all certificates, except MyCertificate.pem in one file AllTrusted.pem, use a text editor, or a command Copy Root.Pem + A.Pem + B.Pem ... Trusted.Pem
Command:
openssl.exe s_client CAfile Trusted.Pem -connect google.nl:443
Replace google.nl:443 with the proper address and port
Reply, something similar to:
CONNECTED(00000124)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIhWDCCIECgAwIBAgIQaEMB4EOx3++GhdWADJfgEjANBgkqhkiG9w0BAQsFADBU
...
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
The server sent a certificate to identify itself. The client should use this certificate and its trusted CA-chain to check the identity of the server.
To continue communicating, we need a PEM file that contains the mentioned issuer and its issuers until the root. Use the procedure described above to get a complete certificate chain, and add all certificates in the correct order to a file trusted.pem. If you copy-paste the received certificate to a PEM file (text), you should be able to verify this received certificate the same way as I verified MyCertificate.Pem as described above.
Once the CA certificates for the received certificates were installed, my openssl s_client command replied with:
...
SSL handshake has read 8945 by
Verification: OK
---
New, TLSv1.2, Cipher is ...
Server public key is 2048 bit
Start Time: 1551779993
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
So the certificate chain to identify the server is accepted.
Idintify me to the server
The next step will be to check if I can identify myself at the server using MyCertficate.pem.
This is the first time I need my private key file. We'll use curl for this:
Command:
curl.exe -v --cacert trusted.pem --cert MyCertificate.pem --key MyPrivate.key https://...
-v: verbose
--cacert: the text file with the concatenation of the trusted CA chain until the root, as verified using openssl verify
--Cert: the certificate to be used by me to identify myself
--Key: the private key for this certificate
Reply:
...
* successfully set certificate verify locations:
* CAfile: trustall.pem
...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
...
* Server certificate:
* subject: C=NL; ...
* start date: Apr 19 12:10:31 2016 GMT
* expire date: Apr 19 12:10:31 2019 GMT
...
* issuer: C=NL; O= <description of certificate issuer; should be in trusted.pem>
* SSL certificate verify ok.
> GET /exchange/ciot HTTP/1.1
> Host: ....
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
What we see:
TrustAll.Pem contains the trusted certificates
(Out) Client Hello - (In) Server Hello: apparently we are on speaking terms
Server sends certificate and requests one
Client sends its certificate to identify itself
Display of the received certificate, the one with which the server identifies itself. The issuer is expected to be in trusted.pem
The received certificate is verifies and accepted. Data transfer can start
Because I didn't send any data, the response is a 400 Bad Request
So this is enough to know that both client and server use trusted certificates and that communication is possible
I'm trying to download files from noaa ncep site, but I get this error
usuario#wrf:~/wrf_data/GRIB$ curl https://ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2019020700//gfs.t00z.pgrb2.1p00.f000 -sslv3
* About to connect() to ftp.ncep.noaa.gov port 443 (#0)
* Trying 140.172.138.66... connected
* Connected to ftp.ncep.noaa.gov (140.172.138.66) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
* Closing connection #0
I could download the files until Tuesday, I used this..
curl -O $FILEDWLT
The version
curl --version
curl 7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
I tried with wget and get similar error. I used a debian machine (squeeze), its old but for now is all I have.
Someone can guide me please?
Best Regards
Carina
tl;dr
Git on Windows stops connecting to github because of mysterious "SSL protocol" errors. Halp!
The Issue
I'm developing on Windows, using a private GitHub repo for source control. When I first boot my system, I'm able to access the remote repo without issue - pull, push, fetch, etc. all work just fine.
After some amount of time(*), this stops, and I get the following error:
fatal: unable to access 'https://github.com/our-team/private-repo.git/': Unknown SSL protocol error in connection to github.com:443
(*) The amount of time seems variable - I've witnessed as little as an hour or two, up to a whole day. Usually after coming back from the system sleeping, it seems to be an issue, but I don't know if it's caused by a time delay or by the system sleeping.
Checking via cURL, I get
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to github.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to github.com:443
Using set GIT_CURL_VERBOSE=1 with git pull shows similar information. Sometimes it succeeds (see below), but most of the time it fails.
Further Notes
There's a little bit of a sporadic nature to it - sometimes I can get requests to succeed, but once it starts exploding, it's generally broken 9 out of 10 requests or more.
A successful cURL request looks like:
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* TLSv1.0, TLS handshake, Server hello (2):
* TLSv1.0, TLS handshake, CERT (11):
* TLSv1.0, TLS handshake, Server finished (14):
* TLSv1.0, TLS handshake, Client key exchange (16):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* Server certificate:
* subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; street=548 4th Street; postalCode=94107; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: 2014-04-08 00:00:00 GMT
* expire date: 2016-04-12 12:00:00 GMT
* subjectAltName: github.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
* SSL certificate verify ok.
> GET /our-team/private-repo.git/ HTTP/1.1
> User-Agent: curl/7.41.0
> Host: github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Mon, 11 May 2015 15:19:43 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://github.com/our-team/private-repo/
< Vary: Accept-Encoding
< X-Served-By: 76f8aa18dab86a06db6e70a0421dc28c
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host github.com left intact
The Question
I've googled a good bit on trying to find this (over the course of several weeks, so I don't have links), but most suggestions seem to point at certificate errors or OpenSSL version mismatches / bugs (which wouldn't be sporadic like this AFAIK).
What might be causing this failure, and how can I resolve it?
Relevant Software:
λ git --version
git version 1.9.5.msysgit.1
λ curl --version
curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Oddly, it turns out that the issue is that the laptop was throttled because of a weak power supply. The docking station I was using was plugged into a low-amp powersupply (3.3 A), which, while it was compatible with the laptop, immediately kicked it into a heavily-throttled mode.
Apparently, this slowed everything down enough that the SSL handshake wasn't able to complete fast enough.
We finally tracked it down after reading a Dell support forum post (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) that discussed slowness issues. The solution there was to change the power supply.
I had also experienced this slowness, but I did not think it was related. We swapped to a high-amp power supply for the dock, and everything was fine again, and the SSL errors described above went away.
That looks like an error which could result from the security initiatives taken after the Logjam attack -- weakdh.org --.
That resulted in the suppression of some ciphers accepted in a SSL/TLS transaction.
Note that, as reported in "Cannot communicate securely with peer: no common encryption algorithm(s)", you will be able to pass the right cipher list to curl via git.
Before that, you can also try if the issue persists while using a more recent Git for Windows (like the Git 2.4.1)
Had the same issue. Disabled my wifi connection and switched to cable and everything works again. Btw: Used a Dell in Docking-Station too.
I'm on Windows attempting to use cURL using SSL, but running into certificate issues that I absolutely cannot figure out.
For example, here is an example of what I'm trying to run.
$ curl "https://google.com" --ntlm -v --negotiate -u USERNAME:PASSWORD --proxy "PROXY" --cert "c:\temp\curl-ca-bundle.crt"
* Adding handle: conn: 0x147ce88
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x147ce88) send_pipe: 1, recv_pipe: 0
* About to connect() to proxy PROXY port 8080 (#0)
* Trying 192.168.134.80...
* Connected to PROXY (PROXY_IP) port 8080 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.30.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* unable to use client certificate (no key found or wrong pass phrase?)
* Closing connection 0
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)
Attempting to use --cacert instead of --cert yields the following message -
* Adding handle: conn: 0x130cdf8
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x130cdf8) send_pipe: 1, recv_pipe: 0
* About to connect() to proxy PROXY port 8080 (#0)
* Trying 192.168.135.80...
* Connected to PROXY (PROXY_IP) port 8080 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.30.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
* CAfile: c:\temp\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use the
-k (or --insecure) option.
The curl-ca-bundle.crt I have is from here, which was update a few minutes ago. I ensured the file is not blocked by Windows.
For what it's worth, I'm behind a corporate proxy and firewall. I have read everything I could find on this issue and don't know what to do next. I do realize I can ignore SSL, but would like to avoid this at all costs.
For what it's worth, I'm behind a corporate proxy and firewall. I have read everything I could find on this issue and don't know what to do next. I do realize I can ignore SSL, but would like to avoid this at all costs.
I would suggest the firewall does SSL interception, i.e. it works as a man-in-the-middle. To inspect encrypted connections it will split it into two encrypted connections, but of course it will not be able to sign the connection between browser and proxy with the original certificate. Thus it will create a new certificate, signed by a CA specific to the firewall. You need to add this CA to your CA bundle or the verification will fail.
For more details you might try to access the target site with a web browser and check the CA which signed the servers certificate or ask your system administrator for details of the SSL interception.
I've been trying to install RVM all day and I've been hung up this entire time by curl, which refuses to connect to https://github.com.
Here is my current error: curl: (35) error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm
Here is the log output when I use the verbose flag:
* About to connect() to github.com port 443 (#0)
* Trying 192.30.252.130...
* Adding handle: conn: 0x100805400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x100805400) send_pipe: 1, recv_pipe: 0
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /System/Library/OpenSSL/certs/cacert.pem
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm
* Closing connection 0
I'm on a 2011 MacBook Pro running Mavericks (10.9.2). Brew says that my curl and my openssl are up to-date.
Originally, curl was telling me that github didn't have the proper SSL certificate, but I managed to finally get around that with this command: export CURL_CA_BUNDLE="/System/Library/OpenSSL/certs/cacert.pem"
Any help would be greatly appreciated!
I had the same error; I tried the "-k" option and it worked.
I figured it out. Turns out, my environment wasn't using the system curl, it was using Anaconda's version of curl, which was outdated and not linked to OSX's keychain. I simply used conda
remove curl to get rid of it and everything seems to be working fine now.