0

I'm in charge of a web server running apache which hosts around 15 differente sites. Now one site needs to communicaten with the other, our devs trying to connect to it via curl using PHP. This doesn't work. I tried to debug it on the command line via:

curl --verbose https://deutsche-unterstuetzungskasse.de

And it gives me error 60 (stated in the topic title), which is quite strange b/c with all the other pages it works.

More verbose:

* About to connect() to deutsche-unterstuetzungskasse.de port 443 (#0)
*   Trying 195.244.228.197...
* connected
* Connected to deutsche-unterstuetzungskasse.de (195.244.228.197) port 443     (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* 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
...

All our pages are equipped with a working ssl certificate as well as the one that doesn't work. Only difference seems to be that this one doesn't got a wildcard certificate. If I set the curl option --cacert /etc/ssl/certs/ca-certificates.crt it works just fine but it doens't really solve the problem. Here the verbose output:

* About to connect() to deutsche-unterstuetzungskasse.de port 443 (#0)
*   Trying 195.244.228.197...
* connected
* Connected to deutsche-unterstuetzungskasse.de (195.244.228.197) port 443     (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* 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 ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: C=DE; postalCode=22303; ST=Hamburg; L=Hamburg; street=Barmbeker Stra�e 2-6; O=Cevo Systemhaus AG; OU=IT; CN=deutsche-unterstuetzungskasse.de
*        start date: 2017-10-19 00:00:00 GMT
*        expire date: 2019-01-17 23:59:59 GMT
*        subjectAltName: deutsche-unterstuetzungskasse.de matched
*        issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Organization Validation Secure Server CA
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: deutsche-unterstuetzungskasse.de
> Accept: */*
> 
...

Can anyone help me out on this? I'm at the end of my knowledge

EDIT:

So I did some further research and found this neat SSL Server Test:

https://www.ssllabs.com/ssltest/analyze.html?d=deutsche-unterstuetzungskasse.de

It seems that this shows my problem. Somehow the server gives *c-core.de as alternative names within the second certificate. How can I fix this?

2 Answers2

1

I managed to fix this issue! As Simon Greenwood stated it may have something to do with old software, which was the case but curl was already up-to-date. I upgraded Apache and openssl, which then presented me another errror:

.."certificate routines:X509_STORE_add_cert:cert already in hash table"

I couldn't find much on google or elsewhere, but somewhere someone said that the command

c_rehash

could fix this. And in the end it did! I still have the issue with the wrong names in the certifcate, but it doens't seem to bother curl anymore further.

  • When a program using SSL wants to locate a trusted certificate, it will compute a hash of the DN of the certificate it's looking for, and will look for a file with the filename matching that hash. If the files don't have the proper hash name, they can't be found. The program `c_rehash` will recreate those files - see [the man page for c_rehash](https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html), so that the programs will be able to find the files. – Jenny D Nov 29 '17 at 15:15
0

Are the wildcard certificates from the same issuer? On the evidence it would look like you don't have a valid CA for Comodo. In your apache configuration you would usually have settings for SSLCertificateFile and SSLCertificateChainFile so check that.

Simon Greenwood
  • 1,363
  • 9
  • 12
  • I'm not sure what I should check there. SSLCertificateFile, ChainFile and Key are pointing to the correct files. The wildcard certificates are issued by AlphaSSL –  Nov 29 '17 at 10:15
  • Then it's cURL that has the problem, it needs updating with an up to date cipher bundle, which may or may not be possible depending on the OS. This is the way to do it on Redhat/CentOS: https://techjourney.net/update-add-ca-certificates-bundle-in-redhat-centos/ The second cert is probably due to your web server not supporting SNI. You either need unique IP addresses for each domain or a more up to date version of your web server. – Simon Greenwood Nov 29 '17 at 10:45