[MacPorts] #42718: certsync fails to verify macports.org certificate
#42718: certsync fails to verify macports.org certificate --------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Keywords: | Port: certsync --------------------------+----------------------- We recently got a new SSL certificate for macports.org, from a different organization, and certsync fails to verify it confirmed on multiple machines and OS X versions: {{{ $ sudo port -v sync ---> Updating the ports tree Synchronizing local ports tree from file:///Users/rschmidt/macports/dports Updating '/Users/rschmidt/macports/dports': svn: E230001: Unable to connect to a repository at URL 'https://svn.macports.org/repository/macports/trunk' svn: E230001: Server SSL certificate verification failed: certificate has expired Command failed: /opt/local/bin/svn update --non-interactive /Users/rschmidt/macports/dports Exit code: 1 }}} {{{ $ curl https://www.macports.org/ curl: (60) SSL certificate problem: certificate has expired 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. }}} {{{ $ openssl s_client -connect www.macports.org:443 -CAfile /opt/local/etc/openssl/cert.pem CONNECTED(00000004) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify error:num=10:certificate has expired notAfter=Jan 28 12:00:00 2014 GMT verify return:0 }}} Using curl-ca-bundle instead of certsync, there is no problem. Analysis from Rainer:
I see in Keychain there are two certificates named "GlobalSign Root CA", and the one used here expired in January 2014, while the other one would be valid until January 2028. It's certainly using the wrong certificate, but I don't know yet why that happens.
Maybe certsync compares them by name in a dictionary instead of using a unique key identifier and that mixes them up?
-- Ticket URL: <https://trac.macports.org/ticket/42718> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: assigned Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: certsync | ---------------------------+----------------------- Changes (by landonf@…): * status: new => assigned * priority: Normal => High -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: assigned Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: certsync | ---------------------------+----------------------- Comment (by raimue@…): The valid "GlobalSign Root CA" is actually a re-signed certificate with a longer lifetime using the same modulus/exponent from the older one that expired end of January 2014. They both have the '''identical''' public key. After some more analysis, the curl-ca-bundle only contains the "GlobalSign Root CA" certificate that is valid throughout 2028, while certsync includes them both into the same bundle. It seems like OpenSSL cannot handle the same certificate twice in a bundle. ''Side note: I will attach a small perl helper script which I used to split the certificate bundle into the original certificates, so they can be examined using `openssl x509 -text -noout -in <file>.pem`.'' With experiments I got it to work when switching the order of the certificates, but it's not working again when adding another one. I guess it's up to some hash algorithm which one gets used, so a different order is not a reliable fix. It seems like the only fix would be to leave out that expired certificate... I see two solutions: ==== Don't export any expired certificate Which means using this CA in a chain would be reported as "untrusted" instead of "expired". That solves this immediate problem because the older "GlobalSign Root CA" certificate is expired now. It might not work in other cases. This is relatively easy to accomplish as we only need to check the expiry date against the current date. ==== Only export one valid/non-expired certificate per public key This means certsync needs a special case to check for duplicates and decide for the one with the later expiry date. Needs a hash/dictionary with the key being the public key of the cert and some more checking. -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: assigned Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: certsync | ---------------------------+----------------------- Comment (by landonf@…): I've attached patch-mktemp-fixes-v0, which contains a proposed fix; testing+review is much appreciated before I commit it to the repo. Based on Raimue's comments, I implemented the first option; to check for certificate validity, I actually set up a SecTrustRef with the only anchor being the certificate being tested, and then evaluate self-trust of the certificate. If this fails, the certificate is expired or otherwise untrustable, even if it's marked as trusted. This approach should resolve the observed problem. Longer-term, I think it's more reasonable to go with the second option (Only export one valid /non-expired certificate per public key), and evaluate certificates according to internal heuristics based on what OpenSSL/gnutls will actually require. However, that requires a better API/model for working with certificates, and probably has to wait for the larger work I'm doing on implementing a certsync Security.framework-backed PKCS#11 module: https://opensource.plausible.coop/src/projects/CRTS/repos/certsync -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: assigned Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: certsync | ---------------------------+----------------------- Comment (by cal@…): That doesn't seem to be the correct patch (or I don't understand where to apply it). -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: assigned Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: certsync | ---------------------------+----------------------- Comment (by landonf@…): I'm a space cadet. Attached the correct patch as patch-handle-expired- certs-v0 -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: assigned Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: certsync | ---------------------------+----------------------- Comment (by raimue@…): Thank you for working on this. I just installed the patched version and I am now able to verify `svn.macports.org` against the generated bundle. I also confirmed with a diff against the older `cert.pem` that the newly generated version only misses expired certificates as expected. Just a minor note on one comment in the patch, "''OpenSSL will simply use whichever certificate is listed first''" is not quite correct, as in my experiments just swapping the order was not enough in all cases. -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#42718: certsync fails to verify macports.org certificate ---------------------------+----------------------- Reporter: ryandesign@… | Owner: landonf@… Type: defect | Status: closed Priority: High | Milestone: Component: ports | Version: 2.2.1 Resolution: fixed | Keywords: Port: certsync | ---------------------------+----------------------- Changes (by landonf@…): * status: assigned => closed * resolution: => fixed Comment: Thanks! Comment updated and patch committed in r117895. -- Ticket URL: <https://trac.macports.org/ticket/42718#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts