0

I am configuring a new web application server running Ubuntu 16.04. The only thing "unusual" I have done is install php 5.6 instead of php7. Php5.6 however does require a valid root certificate and I am getting errors in a variety of apps that care about this. Curl, cron, etc.

I have tried a variety of fixes to get this resolved with no improvement. Such as https://github.com/composer/composer/issues/3346#issuecomment-76593763 and https://stackoverflow.com/questions/35821245/github-server-certificate-verification-failed/35824116#35824116 and How do I install a root certificate?

Still no luck. The cron job I am running still generates:

curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none 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.

  • Thanks. That seems to be for self signed certificates, and I thought I understood that they are to be avoided. That page in fact says as much. Is this really what I want to do? It's a production server. – Rob Brandt May 1 '17 at 23:21
  • You tried installing a commercial cert I suppose? – George Udosen May 1 '17 at 23:23
  • I tried following the steps in the instructions I pasted into the original question; one of these included getting a .pem from curl.haxx.se, which I wouldn't call "commercial" I guess but not self signed either(?). This is what has me confused. I've installed dozens of commercial certs on dozens of web sites, but I've never had to jump through hoops with certs just to get basic php services to run. I don't really know what's needed. Seems very strange to me that a commercial cert would be needed just to get php to run. – Rob Brandt May 1 '17 at 23:26
  • Yes I agree its indeed strange and new to me. – George Udosen May 1 '17 at 23:42
0

I suggest to check the validity of the web server certificate . The steps you describe are correct, but let's get the facts about the certificate.

The steps below, I use for troubleshooting the web server certificate.

  • Check if the server name you expect is in the /CN option in subject:

(SERVER_COMMON_NAME is the webserver who you want to contact)

 echo | openssl s_client -servername ${SERVER_COMMON_NAME} \
    -connect ${SERVER_COMMON_NAME}:443 2>/dev/null | \
    openssl x509 -noout -subject

Check if the CA is the one you expect (the supplier of the cerficate):

echo | openssl s_client -servername ${SERVER_COMMON_NAME} \
            -connect ${SERVER_COMMON_NAME}:443 2>/dev/null | \
        openssl x509 -noout -issuer

Check the /CN field in issuer line.

  • Check the dates of the certificate
echo | openssl s_client -servername ${SERVER_COMMON_NAME} \
        -connect ${SERVER_COMMON_NAME}:443 2> /dev/null | \
        openssl x509 -noout -dates

Check the 'notBefore' and 'notAfter' results.

  • If the above looks good, then test with curl AND specifing the CA root certificate file:

    curl --cacert certs/the_ca.cert.pem -I https://${SERVER_COMMON_NAME}:443

If --cacert option works then check if the CA-root file is system wide known.

Ommit the --cacert. If curl gives an error, then the ca-root-file is NOT installed in the system ca-certificates directory.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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