Some HTTP clients accept this certificate, while others do not. What can make a difference?
Short answer: load balancing, shared hosting and SNI.
Long answer ... first, here is the certificate analysis. We need to go through at least this so that there are no obvious errors.
In the dump below is the name of the wildcard DNS in the Common Name. Placing a DNS name in CN is outdated for both the IETF and CA / Browser Forums. The Friendly Name must be placed in CN because it is displayed to the user. Although deprecated, it is not prohibited.
Instead, DNS names should be in the alternate name of the object. There should be two of them. The first will be lucidpress.com , and the second will be *.lucidpress.com . You just need lucidpress.com because the wildcard must match the label.
For reference, the IETF devalues the DNS name in CN in RFC 6125 . Section 3.1 Server Identification; and section 6.4.4 Checking Common Names.
CA / Browser forums devalue the DNS name in CN in Initial Requirements (BR) Section 9.2.2 Subject Common Name Field. In addition, according to CA / B, an alternative subject name is required. See Section 9.2.1 Extending an alternate object name.
Related: RFC 6125, section 6.4.3, also does not allow matching *.lucidpress.com with lucidpress.com . CA / B BR covers wildcards in Section 11.1.3, but it does not discuss the relevant rules.
With the background information above and the certificate below, this is what happens.
You have two names in the default certificate. Apache serves it by default, because its first <virtual host > in the configuration file .
lucidchart.com*.lucidchart.com
You have 2 names in your Lucid Press certificate.
lucidpress.com*.lucidpress.com
I think the difference in server name (SNI). This is a TLS extension, so you need TLS 1.0 or higher. Those who have no problems get Lucid Press certification and use TLS 1.0 or higher with SNI; those with problems receive a default certificate and use SSLv3 or not SNI. Windows XP will use TLS 1.0, but not SNI, so its experience often arises in the field due to the deployment base.
Browsers accept this because they use TLS 1.0 or higher and send the SNI extension. Since SNI allows your Apache server to choose the right certificate during a handshake, there is no problem matching names.
Java rejects it because it uses SSLv3, even if you say SSLContext.getInstance("TLS"); . You have to jump through some hoops to make sure that you really get TLS 1.0 and higher. There are a few questions about stack overflows. See, for example, Which Cipher Suites to enable for SSL Socket? .
Python rejects it because I assume you are using 2.x or you are allowing SSLv3. You need 3.0 or more to get SNI. See Python 3 Support? in the Python FAQ.
wget added SNI support in version 1.14 . I suspect wget does not enable it or use SSLv3.
cURL probably ensures that SNI is used, if available. Daniel is very careful and he is trying to provide a hassle-free experience and a safe pose out of the box.
In the OpenSSL dump, the parameters of interest are -tls1 -servername . You can get TLS without SNI by omitting -servername . Therefore, you need both tls1 and -servername <host> .
$ openssl s_client -tls1 -servername www.lucidpress.com \ -connect www.lucidpress.com:443 | openssl x509 -text -noout depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 Certificate: Data: Version: 3 (0x2) Serial Number: 12250220837273305 (0x2b8582cd6cfed9) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http:
$ dig www.lucidchart.com ; <<>> DiG 9.8.5-P1 <<>> www.lucidchart.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19608 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.lucidchart.com. IN A ;; ANSWER SECTION: www.lucidchart.com. 8 IN CNAME chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 107.23.98.6 chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 54.236.129.63 chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 54.88.154.168 ;; Query time: 23 msec ;; SERVER: 172.16.1.10
If this is interesting, this is from sslscan :
Prefered Server Cipher(s): SSLv3 256 bits DHE-RSA-AES256-SHA TLSv1 256 bits DHE-RSA-AES256-SHA TLSv1.1 256 bits DHE-RSA-AES256-SHA TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384