There seems to be a problem regarding SNI (TLS Server Name Indication) with the OpenSSL 1.0.1l installed in the base system of FreeBSD 10.1. For example: OpenSSL 1.0.1l in base system /usr/bin/openssl s_client -servername chrismeller.com -connect chrismeller.com:443 returns "Verify return code: 20 (unable to get local issuer certificate)" OpenSSL 1.0.2c from ports /usr/local/bin/openssl s_client -servername chrismeller.com -connect chrismeller.com:443 returns "Verify return code: 0 (ok)"
This is a bug with OpenSSL since 1998 and fixed in 1.0.1n. The bug is that default CApath is not consulted unless CAfile or CApath is also supplied and loaded successfully. This fix is OpenSSL changeset fe9b85c3cb79f1e29e61f01de105b34ce8177190 . The OpenSSL's SNI support worked just fine otherwise, in my testing. If you explicitly pass the right root CA's, it would also work. This have been fixed in 10.2-RELEASE (currently 10.2-PRERELEASE and soon would be 10.2-BETA1), but since this one affects only the testing program and it have been there for more than a decade with this first complain, we can reasonably consider it as a low impact one and therefore no EN is planned for it, so mark this as "Overcome By Events".
I think it doesn't affect only the testing program. Apache24 also has a problem with this. See: https://github.com/owncloud/core/issues/17446
(In reply to g_amanakis from comment #2) Would you be more specific about the Apache24 issue? I did see your comment about it in the github issue but there is not any details (if you use SSLStrictSNIVHostCheck on, Apache would refuse to start if OpenSSL is not SNI capable). My personal website uses SNI and it's using base system OpenSSL by the way.
Running apache24 from packages or ports (compiled against OpenSSL 1.0.1l from the base system) with "SSLStrictSNIVHostCheck on" in httpd-ssl.conf doesn't complain. However when I try to install apps in Owncloud 8.1 it fails by producing the message "cURL error 60: See http://curl.haxx.se/libcurl/c/libcurl-errors.html". Compiling apache24 against the OpenSSL 1.0.2d from ports resolves the issue. I assumed that since the testing client (s_client) doesn't properly function, the same would apply to mod_ssl from apache24.
Just tested Owncloud with OpenSSL 1.0.1o of the base FreeBSD 10.2-PRERELEASE and the problem is resolved. The culprit seems to be OpenSSL 1.0.1l in FreeBSD-10.1.
(In reply to g_amanakis from comment #4) Looking at curl page, 60 means CURLE_SSL_CACERT, which means it was unable to verify your SSL certificate against a known CA and for a non-working SNI it should be CURLE_PEER_FAILED_VERIFICATION. Can you reproduce the problem with only OpenSSL as the variable?
(In reply to Xin LI from comment #6) Yes, I can reproduce the problem with OpenSSL 1.0.1l as the only variable (e.g. installed from ports and having apache24 compiled against it).
Assigning to Apache maintainers for further investigation. FWIW my nginx SNI worked just fine on 10.1-RELEASE with OpenSSL 1.0.1l.
My site is also using SNI and 10.1-RELEASE, but with nginx
This bug affects curl too, not just openssl cli itself. gslin@FreeBSD [~] [02:22] uname -a FreeBSD FreeBSD.cs.nctu.edu.tw 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov 2 10:11:50 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 gslin@FreeBSD [~] [02:22] curl -v https://i.kfs.io/robots.txt * Trying 118.214.255.182... * Connected to i.kfs.io (118.214.255.182) port 443 (#0) * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /usr/local/share/certs/ca-root-nss.crt CApath: none * TLSv1.0 (OUT), TLS handshake, Client hello (1): * TLSv1.0 (IN), TLS handshake, Server hello (2): * TLSv1.0 (IN), TLS handshake, Certificate (11): * TLSv1.0 (OUT), 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 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.
Is this bug still relevant? Meanwhile 9.3 has been EoL for a while and I can't reproduce. $ uname -a FreeBSD gw.example.org 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Sun Mar 15 14:00:33 CET 2015 root@gw.example.org:/usr/obj/usr/src/sys/EXAMPLE101 i386 $ openssl version OpenSSL 1.0.1l-freebsd 15 Jan 2015 Tested against an OpenSSL 2.4.29 using SNI I get the correct cert response.
(In reply to Bernard Spil from comment #11) > Tested against an OpenSSL 2.4.29 using SNI I get the correct cert response. Surely this is an Apache 2.4.29, not OpenSSL.
I close here. Please reopen if the problem is still there