openssl: default CApath not honored for tools built against openssl

[dj_mook@…]

If I install a certificate or certificate bundle to /opt/local/etc/openssl/certs and use c_rehash to generate the hashed symbolic link, openssl and tools linked against it (ie- wget) do not use the certificate.

The only way to get it to see the certificate is to append it to the cafile location of /opt/local/etc/openssl/cert.pem. Only certificates in that file are honored.

To test this I do the following:

• rename /opt/local/etc/openssl/cert.pem so it is not interfering with the test.
• install google's cert chain (www.google.com,thawte,versign) to /opt/local/etc/openssl/certs/
• run /opt/local/bin/c_rehash to install the hashed links to the certs
• run openssl s_client -CApath /opt/local/etc/openssl/certs/ -connect www.google.com:443 and succeed
• run wget -O - ​https://www.google.com and fail with:

  ERROR: cannot verify www.google.com’s certificate, issued by “/C=/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA”:
    Unable to locally verify the issuer’s authority.
  

• run lynx ​https://www.google.com and fail with:

  Making HTTPS connection to encrypted.google.com
  SSL callback:unable to get local issuer certificate, preverify_ok=0, ssl_okay=0
  Retrying connection without TLS.
  Looking up encrypted.google.com
  Making HTTPS connection to encrypted.google.com
  SSL callback:unable to get local issuer certificate, preverify_ok=0, ssl_okay=0
  Alert!: Unable to make secure connection to remote host.
  
  lynx: Can't access startfile https://www.google.com/
  

• if the certificates are appended to /opt/local/etc/openssl/cert.pem then wget and lynx requests to ​https://www.google.com work

This issue affects all tools built again openssl.

[dj_mook@…]

This was filed at the macports trac since this issue does not present on other platforms I've tested with openssl. Googling around always ends up with someone suggesting to install the cert bundle to the CAfile location of /opt/local/etc/openssl/cert.pem which works around the problem but still leaves the broken state when CApath is preferred over CAfile.

For some reason trac munched the description so it is not displaying correctly. Unfortunately I cannot edit to fix.

[mf2k (Frank Schima)]

I fixed it for you. In the future, look at WikiFormatting and use the Preview button. Also fill in the Port: field and Cc the maintainer as per the ​Ticket Guidelines.

[dj_mook@…]

Is there something else that needs to be done to get movement on this?

[nikolaus@…]

Cc Me!

[raimue (Rainer Müller)]

Related ticket #19247.

[nonstop.server@…]

Cc Me!

[jmroot (Joshua Root)]

Replying to dj_mook@…:

Is there something else that needs to be done to get movement on this?

Providing a patch or an explanation of how and why the problem occurs would do it.

[raimue (Rainer Müller)]

A lot of stuff has changed since this ticket was opened:

• wget is no longer linked against the openssl port
• curl-ca-bundle now installs /opt/local/etc/openssl/cert.pem
• certsync exists as an alternative to curl-ca-bundle

I am not sure whether this problem report is still applicable to the current configuration of the ports. Please report back if the problem still exists.