All Topics
Hi we are getting this issue when trying to deploy our changes to our staging server:
DEBUG [2928de5d] The "//composer.admincolumns.com/download?package=admin-columns/ac-addon-acf&version=2.7" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages: DEBUG [2928de5d] DEBUG [2928de5d] error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed DEBUG [2928de5d] DEBUG [2928de5d] Failed to enable crypto DEBUG [2928de5d] DEBUG [2928de5d] failed to open stream: operation failed DEBUG [2928de5d]I was checking with our server technician and these are his words:
The problem is that they are still serving the old Letsencrypt chain; It's been a disaster for the past two weeks. When connecting this is what I'm seeing: ❯ openssl s_client -showcerts -servername composer.admincolumns.com -connect composer.admincolumns.com:443 CONNECTED(00000005) depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=10:certificate has expired notAfter=Sep 30 14:01:15 2021 GMT verify return:0 depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=10:certificate has expired notAfter=Sep 30 14:01:15 2021 GMT verify return:0 depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=10:certificate has expired notAfter=Sep 30 14:01:15 2021 GMT verify return:09 months, 3 weeks ago
Hi,
Thanks for contacting us. There is a separate thread for this: //www.admincolumns.com/forums/topic/curl-error-60-ssl-certificate-problem-certificate-has-expired/
But I will do my best to answer you. It’s such a vague issue and I too am not 100% clear what is to be done. But here goes.
Do you by any chance know what software your staging site runs? E.g. which version of Ubuntu or another distro? And is everything up-to-date? As you can read: if the consuming code (e.g. your staging) is up to date and has received a patch for this issue; you should be fine really. Even software like Postman has had issues with this and took them some time to properly address the issue.
Disclaimer: I am not a full-time Linux sysadmin, semi-tech rand:
The issue is not in serving an expired cert; it’s in consuming software not reading the entire chain. Modern/ patched software has no issue reading the entire chain and understanding that the cross-signed cert. is actually valid. I am not saying I exclude the option we can do something; but in general, we cannot do a lot about this except being up to date ourselves.
I am open to making changes on our side, but I don’t see what that could be. We are fully up to date with regenerated certs from the LE certbot.
Also check sub-software e.g. update composer to version 2 instead of 1. All systems involved in using SSL on the OS should be up to date / patched.
end semi-tech rand :)
Cheers!
9 months, 3 weeks ago
Hi, we have made sure we have all of our server apps updated and now we see a different error:
DEBUG [7dc37658] [Composer\Downloader\TransportException] The '//composer.admincolumns.com/download?package=admin-columns/ac-addon-acf&version=2.7' URL required authentication. You must be using the interactive console to authenticate DEBUG [7dc37658] install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...Any idea on how to solve that?
9 months, 3 weeks ago
Any news on that?
2 months, 3 weeks ago
You must be logged in to reply to this topic.
Today I wanted to add a package from our internal satis-repository to a composer.json-file. Easy thing! I added the satis-server as repo to the composer.json like this: Fair enough! That’s it! Run composer and be happy:
WTF…???
Ah, yes! The servers certificate is signed by our internal Root-CA. As it’s an internal server that’s what we do. But how to get composer to know that? It took me a while. Adding the Root-Certificate to OpenSSL didn’t bring the expected results (might be due to Homebrew) as didn’t adding the cert to PHPs keystore (might be due to some weird setup on my machine).
But there surely has to be a way of getting satis (or Toran) up and running with self-signed certs!
There were many hacks around that disabled certificate validation altogether but that’s not what I wanted. And after a short question on Twitter I got a few ideas. Alexander Tureks idea was great: Adding “verify-peer” : “false” to the ssl-options of the repository. Sadly that didn’t do the trick. Finally Jordi Boggiano gave me a hint to a feature I hadn’t found in the composer-docs before: Add the RootCA-Certificate to the ssl-options of the repository (and to the project).
So now my composer.json looks like this:
{ "repositories": [{ "type": "composer", "url": "//example.com/satis", "options" : { "ssl" : { "cafile" : "myrootca.crt" } } }] }The file “myrootca.crt” is a PEM-file that only contains the root-certificate. You can get it by calling openssl x509 -in <(openssl s_client -connect example.com:443 -prexit 2>/dev/null) > myrootca.crt. And myrootca.crt needs to be on the same level as the composer.json in your project.
Thanks Jordi for the fast response!
Hope that helps someone 😉
Related posts
Post navigation
By continuing to use the site, you agree to the use of cookies. That includes scrolling or clicking links. (Sorry for the inconvenience…) more information