Can't establish a secure connection with the server - ssl

I have nginx running through cloudflare and I have a weird issue where if I use one domain my website works fine, but the second one I have doesnt work responding that it can't establish a secure connection.
Here is my nginx conf file:
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name tautulli.trever.me stats.plex.trever.me;
ssl_certificate /etc/nginx/ssl/live/trever.me/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/live/trever.me/privkey.pem;
if ($http_x_forwarded_proto = "http") {
return 301 https://$host$request_uri;
}
location / {
proxy_buffers 16 4k;
proxy_buffer_size 2k;
proxy_pass http://10.0.1.1:8181;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Ssl on;
}
access_log /var/log/nginx/tautulli.trever.me/access.log;
error_log /var/log/nginx/tautulli.trever.me/error.log;
}
The first one, tautulli.trever.me, works no issues, however when I try stats.plex.trever.me it tells me it can't establish a secure connection even though I'm using the same cert. I checked the cert, and it has this wildcard SAN in it. Even then I would think it would just throw up a warning and not fail to connect entirely. But here is my cert output:
root#server:/home/trever# openssl x509 -text -noout -in /etc/nginx2/ssl/live/trever.me/cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:39:22:8a:5b:b1:3d:be:53:c7:fd:6d:ae:f4:b4:8b:42:39
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Validity
Not Before: Mar 28 23:56:41 2020 GMT
Not After : Jun 26 23:56:41 2020 GMT
Subject: CN = trever.me
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c8:13:a2:0d:e3:1f:d3:d4:2f:27:39:a1:1e:09:
07:cd:e7:de:05:2e:12:9f:35:78:35:93:29:4e:ca:
26:b3:0f:03:9c:c5:8c:8d:bf:93:72:9c:14:be:61:
86:9e:1c:3e:9e:77:0c:34:d8:3a:d5:17:4b:e3:17:
dc:3b:cf:6a:d1:84:b8:b2:a9:5f:82:1c:dd:db:ca:
ed:8e:fe:cd:9a:de:5f:4e:43:df:eb:de:2d:51:5c:
97:3b:05:b3:fc:d4:50:14:f5:af:00:dc:1e:f4:08:
d7:9a:0c:46:e1:96:7f:84:2b:bd:7e:84:6e:57:b2:
53:d5:03:ff:63:36:ae:fa:b6:71:cb:c1:d9:52:3c:
b0:a5:35:d6:b6:18:84:c3:77:3e:59:88:d8:03:58:
a1:8b:b2:8d:2e:53:ce:a0:cd:c7:6b:a4:0b:1b:66:
2a:61:2b:ef:05:60:f8:ea:e8:f5:ae:30:a0:83:1e:
79:6a:8e:61:6f:39:d5:66:06:c2:bc:7a:7d:89:94:
5b:70:06:4d:0d:79:b9:b7:d5:47:c2:72:a5:a0:a5:
d3:3e:a3:6e:22:d8:77:96:c1:75:cf:ac:f9:48:8d:
5f:72:ef:d6:f6:1c:0f:be:7c:7f:ae:e5:72:03:3a:
65:28:59:8c:2c:3f:91:39:28:0b:13:50:51:3d:af:
1e:37
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
E7:49:A2:6D:69:9C:CE:5C:34:92:76:48:73:5C:DC:A5:FE:17:BC:DB
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:*.plex.trever.me, DNS:*.trever.me, DNS:trever.me
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : F0:95:A4:59:F2:00:D1:82:40:10:2D:2F:93:88:8E:AD:
4B:FE:1D:47:E3:99:E1:D0:34:A6:B0:A8:AA:8E:B2:73
Timestamp : Mar 29 00:56:41.080 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:22:32:47:35:F7:41:8A:51:10:95:73:56:
F5:64:4C:10:2E:FD:4E:06:DA:4E:83:01:22:C3:EB:B6:
08:2A:38:6C:02:21:00:92:CE:5F:76:89:12:2F:91:56:
78:A6:75:FF:31:CD:F3:BF:F4:0F:18:78:92:5F:53:66:
F9:68:E8:75:CF:90:BD
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : B2:1E:05:CC:8B:A2:CD:8A:20:4E:87:66:F9:2B:B9:8A:
25:20:67:6B:DA:FA:70:E7:B2:49:53:2D:EF:8B:90:5E
Timestamp : Mar 29 00:56:41.069 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:35:91:AD:D3:07:D5:D4:00:0A:DC:5F:AB:
F8:BB:A1:BC:75:A2:AE:FF:26:A5:99:7E:37:59:48:FC:
EE:D2:B5:F5:02:20:05:73:58:A0:8F:60:AF:A6:65:27:
38:48:CA:25:30:92:2A:DD:C2:E4:EC:AD:5D:32:D8:31:
59:95:09:07:58:0B
Signature Algorithm: sha256WithRSAEncryption
8f:1a:0f:d3:71:90:8a:f1:ba:de:f4:c3:36:fc:3b:a4:b0:fc:
53:05:1f:3d:a7:a5:21:b2:eb:b2:38:5b:31:5c:37:9a:90:38:
58:9e:25:2b:54:6c:0c:4d:eb:b2:d3:90:54:47:7a:6a:65:78:
9d:65:76:7f:40:e2:39:0a:48:09:ac:4f:aa:a5:31:13:dd:c3:
88:e0:da:e7:b7:21:d0:66:be:56:ae:6e:4d:07:85:33:65:b0:
f2:c0:6a:74:45:db:4b:6c:c5:5a:9d:19:d6:94:f5:23:f1:b5:
74:28:92:04:c5:f4:38:45:48:c9:11:a6:bc:1e:b7:1d:9d:35:
dc:ce:0d:28:83:30:30:23:6a:44:35:32:c3:f1:58:f1:f5:e3:
61:95:8a:da:26:c0:87:b9:10:dd:4f:20:5e:19:4b:6a:aa:8b:
8a:64:52:0f:1f:db:1a:f1:cb:5e:5e:9f:88:b0:f9:d3:76:ad:
25:11:7f:74:02:b5:48:f7:18:ad:66:68:01:ce:1d:2e:49:eb:
ab:77:1f:bf:dd:3c:26:19:6e:1b:cd:22:de:5d:96:f1:5e:7a:
74:f8:8b:d9:43:a1:77:d1:d5:0c:5d:d5:fb:cf:fc:ca:fd:3f:
42:53:7d:7c:4f:c6:47:9b:9d:75:c3:92:ca:36:d8:4b:0a:e9:
4a:35:15:15
Why would it work with one domain and not the other using the same configs?

Did you try to create two separate Nginx file for both the servers?
Try to create separate nginx file and run: sudo nginx -t
Is your SSL certificate is for *.trever.me ? If not try to generate a separate certificate for both the server.

Related

cloudflare ssl for staging subdomain: sslv3 alert handshake failure

I have the following setup
cloudflare -> aws nlb -> ingress nginx controller (aws eks) -> kubernetes service -> kubernetes pod.
Cloudflare has edge certificates enabled for
*.project.com, project.com and are installed in ingress-nginx as
Cloudflare has origin server ssl cert for
*.staging.project.com, *.project.com, project.com (3 hosts) that I installed inside kubernetes cluster.
extraArgs:
default-ssl-certificate: ingress-nginx/cloudflare-origin-cert
However I'm unable to connect to argocd.staging.project.com via HTTPs due to handshake error. It should work as origin server cert has *.project.com and also *.staging.project.com.
Inside cloudflare I have just a single domain "project.com", as it seems cloudflare does not allow me to have a staging hosted zone.
What am I missing or doing wrong?
prod env works just fine with this setup, but not staging. I can change argocd.staging.project.com > /argocd-staging.project.com and everything would work, but I prefer to keep staging subdomain if possible.
DNS is working properly as in http call I get logs in ingress-nginx
✗ curl http://argocd.staging.project.com
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx</center>
</body>
</html>
but in curl https I don't see any logs inside ingress-nginx pod.
curl https://argocd.staging.project.com
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
echo | openssl s_client -showcerts -servername argocd.staging.project.com -connect argocd.staging.project.com:443 2>/dev/null | openssl x509 -inform pem -noout -text
unable to load certificate
139926728525632:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
cert info
openssl x509 -text -noout -in cloudflare-origin.cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0e:e8:98:22:e2:06:be:6d:18:ba:53:49:ef:ac:3a:ae:2b:a8:d3:e1
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = "CloudFlare, Inc.", OU = CloudFlare Origin SSL Certificate Authority, L = San Francisco, ST = California
Validity
Not Before: Dec 28 00:48:00 2021 GMT
Not After : Dec 24 00:48:00 2036 GMT
Subject: O = "CloudFlare, Inc.", OU = CloudFlare Origin CA, CN = CloudFlare Origin Certificate
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:6e:4b:53:c7:bb:a3:7a:e4:52:79:39:20:c7:
67:1f:67:06:13:ad:8d:cf:48:ae:56:c0:ab:22:e7:
5f:22:1b:bb:35:24:74:62:1a:11:5e:be:c3:a7:70:
26:54:65:28:e5:bf:4c:d9:de:cc:1a:55:bf:e4:c4:
32:93:84:1f:7c:81:01:bb:20:74:72:e0:c9:f4:cc:
47:70:76:5e:e7:ce:43:cd:4f:5e:23:7b:b7:66:ac:
e6:ce:3a:1d:8f:1c:c1:5e:61:c2:da:64:46:6c:22:
00:4d:8a:97:ab:40:93:a8:dd:35:f0:26:43:a4:af:
25:5e:2f:27:d5:29:0a:e5:bf:c7:8f:79:8c:3d:07:
66:08:23:f9:a8:72:2b:e5:82:d9:90:a3:56:c5:4c:
be:a9:2a:12:90:e4:6c:0b:e4:12:45:9f:a9:e9:7c:
4b:66:36:3e:ff:f7:2b:a2:49:5d:6d:ef:7e:f4:3e:
5c:cf:7f:d2:70:e9:4f:06:c0:ca:ca:5f:ec:22:f7:
06:c0:0e:2d:f5:9f:b3:4c:0c:2f:b2:2e:fc:06:6a:
de:07:fa:cc:99:fa:83:35:a3:6d:48:13:da:23:2c:
52:9c:2f:30:0e:23:cc:af:e8:d1:31:cd:5d:95:bf:
cd:ba:43:91:06:c2:b4:b4:bc:ad:c2:e6:01:83:25:
d3:41
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
13:86:11:20:22:E5:81:ED:B9:8A:5C:04:0F:3F:03:34:E1:86:55:0C
X509v3 Authority Key Identifier:
keyid:24:E8:53:57:5D:7C:34:40:87:A9:EB:94:DB:BA:E1:16:78:FC:29:A4
Authority Information Access:
OCSP - URI:http://ocsp.cloudflare.com/origin_ca
X509v3 Subject Alternative Name:
DNS:*.staging.project.com, DNS:*.project.com, DNS:project.com
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.cloudflare.com/origin_ca.crl
Signature Algorithm: sha256WithRSAEncryption
63:fd:c0:b0:ad:95:e4:78:d2:d6:ae:62:8c:5d:a2:a6:c9:12:
c0:56:02:2a:ba:04:fd:b7:74:d4:0d:ad:5e:55:78:67:63:1a:
79:83:58:91:b4:a9:77:e1:5e:5d:86:ad:e2:5b:03:a1:88:ff:
88:bb:f4:29:7d:83:96:89:f8:44:a4:4e:79:c3:ab:14:89:15:
ea:af:a5:66:f4:6a:fe:2a:a5:55:de:0f:36:a5:cb:95:59:ee:
3a:51:6b:d3:ca:3c:0a:bc:66:60:ff:77:81:91:57:91:3a:a5:
ea:05:30:aa:69:01:95:48:44:04:e8:78:a7:bf:03:9b:7e:65:
f7:5d:91:5d:a9:a2:67:5a:3c:c8:7f:9e:4e:3f:3a:2a:2a:5a:
68:4b:b5:e2:a1:68:a1:ff:6d:d4:39:9d:00:ab:89:c7:34:aa:
5b:87:fe:ba:61:c2:94:51:5d:59:c5:a0:0a:dc:0c:23:24:19:
bc:37:ad:1f:8c:bd:71:89:63:b2:a8:a3:24:20:fc:dd:0f:d9:
15:b4:a2:b8:8f:7a:c6:a6:50:20:a0:fd:de:1a:79:c6:30:86:
79:bf:ea:46:e3:1b:e6:86:3b:89:67:d2:c5:bf:d8:62:9f:52:
6c:d2:1f:b5:f6:03:56:2b:23:5e:30:7a:3e:78:39:f7:cd:a0:
d0:3c:da:69
However for production environment (staging omitted in URL) everything works and handshake is normal.
echo | openssl s_client -showcerts -servername argocd.project.com -connect argocd.project.com:443 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0e:2d:db:f3:59:21:a2:91:e4:67:79:17:ff:71:8d:e5
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
Validity
Not Before: Jun 15 00:00:00 2021 GMT
Not After : Jun 14 23:59:59 2022 GMT
Subject: C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = sni.cloudflaressl.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:8d:99:4f:55:aa:0c:c2:4d:1b:57:23:e8:73:09:
7f:de:d4:ae:50:f8:19:74:0a:23:0f:cc:3e:64:c1:
bf:66:56:72:06:4a:c5:0c:13:1f:43:b9:d5:f9:88:
e6:f5:4c:4a:02:ee:76:37:9d:ee:e6:26:7d:be:3e:
fc:42:a5:97:20
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:A5:CE:37:EA:EB:B0:75:0E:94:67:88:B4:45:FA:D9:24:10:87:96:1F
X509v3 Subject Key Identifier:
FA:15:4F:CE:7F:3D:C9:27:5A:D3:87:C1:ED:68:A9:FC:CC:BC:E2:84
X509v3 Subject Alternative Name:
DNS:*.project.com, DNS:sni.cloudflaressl.com, DNS:project.com
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/CloudflareIncECCCA-3.crl
Full Name:
URI:http://crl4.digicert.com/CloudflareIncECCCA-3.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.2
CPS: http://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/CloudflareIncECCCA-3.crt
X509v3 Basic Constraints: critical
CA:FALSE
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 46:A5:55:EB:75:FA:91:20:30:B5:A2:89:69:F4:F3:7D:
11:2C:41:74:BE:FD:49:B8:85:AB:F2:FC:70:FE:6D:47
Timestamp : Jun 15 16:30:55.567 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:DD:C3:A2:FE:62:CE:34:30:BF:41:A3:
3D:E3:D3:4B:7A:0C:DD:BF:1E:A0:81:B0:5B:63:0E:A3:
83:6B:5D:AF:5C:02:21:00:C7:5C:0F:71:C9:61:11:5A:
A8:2F:5F:9A:31:A4:2A:C0:83:B6:2A:29:FC:BD:5D:FA:
3C:CF:B5:F6:1E:EE:F0:6B
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 22:45:45:07:59:55:24:56:96:3F:A1:2F:F1:F7:6D:86:
E0:23:26:63:AD:C0:4B:7F:5D:C6:83:5C:6E:E2:0F:02
Timestamp : Jun 15 16:30:55.564 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:25:E2:6B:36:61:E9:F4:EC:28:DE:1D:E3:
18:6F:E2:0A:03:EF:29:45:F3:09:0B:27:45:6F:51:78:
D5:3A:2A:83:02:21:00:A4:34:A0:B5:D5:FD:F2:42:13:
31:93:DF:C4:AD:3E:A7:48:C6:69:C1:9D:04:7A:EA:C7:
27:6E:88:69:9B:B9:BF
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 51:A3:B0:F5:FD:01:79:9C:56:6D:B8:37:78:8F:0C:A4:
7A:CC:1B:27:CB:F7:9E:88:42:9A:0D:FE:D4:8B:05:E5
Timestamp : Jun 15 16:30:55.627 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:FA:13:20:B1:07:70:46:F4:C2:AD:F0:
1C:10:A7:8D:92:23:2C:8A:34:E0:1C:7F:59:8A:CB:7B:
C2:CF:07:95:37:02:20:50:78:FA:DF:8D:A4:9C:B9:73:
1F:18:ED:51:06:33:8D:B4:F6:CC:0D:8D:46:69:CB:AB:
93:17:D2:64:1F:2D:B3
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:fc:1b:7b:6f:de:f2:29:5a:11:0c:92:f8:05:
31:1b:7c:68:f7:6e:e4:0b:5d:15:67:dd:f4:c9:00:d7:77:ad:
46:02:21:00:a0:98:25:6a:19:3b:ac:51:68:f5:de:9d:cc:93:
22:b2:ca:18:c8:e9:ec:06:79:77:01:ba:fb:3a:41:3d:2d:cd
Ok found - it's the limitation of universal cloudflare certificate that doesn't cover subdomains :(
from their docs:
Only some of your subdomains return SSL errors
Symptom Cloudflare Universal SSL and regular Dedicated SSL certificates only cover the root-level domain (example.com) and one level of subdomains (*.example.com). If visitors to your domain observe errors accessing a second level of subdomains in their browser (such as dev.www.example.com) but not the first level of subdomains (such as www.example.com), resolve the issue using one of the following methods below.
Resolution
Ensure the domain is at least on a Business plan and upload a Custom SSL certificate that covers dev.www.example.com, or
purchase a Dedicated SSL certificate with Custom Hostnames that covers dev.www.example.com, or
if you have a valid certificate for the second level subdomains at your origin web server, click the orange cloud icon beside the dev.www hostname in the Cloudflare DNS app for example.com.
See here: https://support.cloudflare.com/hc/en-us/articles/200170566-Troubleshooting-SSL-errors#h_55e4d315-c60d-4798-9c4c-c75d9baed1b7

TLS error using reqwest "A CA certificate is being used as an end-entity certificate; CaUsedAsEndEntity" for self hosted local CA

My app requires the use of reqwest which throws the error
error sending request for url (https://testserver.com/data): error trying to connect: invalid certificate: CAUsedAsEndEntity
I have a self hosted test CA, self signed. My environment is Ubuntu 18.04, openssl 1.1.1.
How can I bypass this error or reconfigure my certificate so that this error doesn't repeat again?
My certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
...
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = ...
Validity
Not Before: Oct 31 22:03:07 2021 GMT
Not After : Oct 31 22:08:07 2121 GMT
Subject: CN = ...
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
....
e8:5d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
...
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
Subject Information Access:
1.3.6.1.5.5.7.48.13 - URI:https://testserver.com/data
X509v3 Certificate Policies: critical
Policy: 1.3.6.1.5.5.7.14.2
sbgp-ipAddrBlock: critical
IPv4:
0.0.0.0/0
IPv6:
::/0
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
0-4294967295
Signature Algorithm: sha256WithRSAEncryption

Nginx SSL Certificate failed SSL: error:0B080074:x509 (Google Cloud)

My server was hosted in Bluehost (Apache), the certificate was working fine. Now, I'm using Google Cloud for multiple pages in NodeJS on different port using proxy_pass. I am trying to configure the SSL but I have problems. I was looking for similar questions, but it still shows the same error. I created the key file following this link
/var/log/nginx/error.log:
2015/07/08 10:47:20 [emerg] 2950#0: SL_CTX_use_PrivateKey_file("/etc/nginx/ssl/domain_com/domain_com.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
When I put on console:
openssl rsa -noout -modulus -in domain_com.key shows me this:
Modulus=D484DD1......512 characters in total......5A8F3DEF999005F
openssl x509 -noout -modulus -in ssl-bundle.crt:
Modulus=B1E3B0A.......512 characters in total......AFC79424BE139
This is my Nginx setup:
server {
listen 443;
server_name www.domain.com;
ssl_certificate /etc/nginx/ssl/domain_com/ssl-bundle.crt;
ssl_certificate_key /etc/nginx/ssl/domain_com/domain_com.key;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
access_log /var/log/nginx/domain_com.access.log;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:8086;
proxy_read_timeout 90;
proxy_redirect http://localhost:8086 https://www.domain.com;
}
}
The problem may occur in case of wrong concatenation order. You tried:
cat www_example_com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > ssl-bundle.crt
Which looks correct, but concatenation usually require to eliminate extra download from root CA, therefore Nginx creator said:
Browsers usually store intermediate certificates which they receive
and which are signed by trusted authorities, so actively used browsers
may already have the required intermediate certificates and may not
complain about a certificate sent without a chained bundle.
The official docs explicitly says:
If the server certificate and the bundle have been concatenated in
the wrong order, nginx will fail to start and will display the error
message:
SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
(SSL: error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch)
because nginx has tried to use the private key with the bundle’s first
certificate instead of the server certificate.
So to solve the problem please try:
Attach www_example_com.crt to ssl_certificate Nginx config key
Download latest Comodo CA certificates SHA2 from official web page and try one more time to concatenate the bundle

400 Bad Request: The SSL certificate error

I get this error when I try to get page with client key and certificate using this command:
curl -v -s --key /home/dmitry/Downloads/client_cert/client.mysite.key --cert /home/dmitry/Downloads/client_cert/client.mysite.crt https://mysite.com/api/login/
Here's what I see in nginx logs:
2014/12/08 06:30:55 [crit] 13087#0: *404 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early) while SSL handshaking, client: xxx.xxx.xxx.xxx, server: 0.0.0.0:443
And here is part of my nginx.conf:
server {
listen 443 ssl;
ssl_certificate /home/mysite/conf/dev/ssl/com.mysite.crt;
ssl_certificate_key /home/mysite/conf/dev/ssl/com.mysite.key;
ssl_client_certificate /home/mysite/conf/dev/ssl/com.mysite.crt;
ssl_verify_client optional;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
server_name mysite.com www.mysite.com;
access_log /home/mysite/logs/nginx_access.log;
error_log /home/mysite/logs/nginx_error.log;
location /api/{
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header SSL-client-serial $ssl_client_serial;
proxy_set_header SSL-client-dn $ssl_client_s_dn;
proxy_set_header SSL-client-verify $ssl_client_verify;
if ($ssl_client_verify != SUCCESS) {
return 403;
break;
}
}
}
Here are the commands I've used to create client cert:
openssl req -out client.mysite.csr -new -newkey rsa:2048 -nodes -keyout client.mysite.key
openssl x509 -req -days 3650 -in client.mysite.csr -CA com.mysite.crt -CAkey com.mysite.key -set_serial 01 -out client.mysite.crt
What could be wrong here? Should I use some other certificate as CA for my client cert than server cert?
UPDATE:
When I do
openssl verify -CAfile com.mysite.crt client.mysite.crt
I get:
error 20 at 0 depth lookup:unable to get local issuer certificate
First of all, enable debug log in nginx.conf:
error_log logs/error.log debug;
And restart nginx. Then repeat the request and check the log file. Find the first line with verify:0:
2019/12/05 22:34:50 [debug] 5980#9776: *17 verify:0, error:20, depth:0, subject:"/CN=...", issuer:"/CN=..."
Here you see error:20. The error code comes from OpenSSL. Here you can find the constant name by code and here the corresponding description by constant name.
Alternatively you can verify the certificate using openssl command line tool:
openssl verify -CAfile ca.crt client.crt
To verify it as the server sees it, ca.crt has to be the file listed in ssl_client_certificate or ssl_trusted_certificate directive in nginx.conf.
To verify the certificate on its own, ca.crt has to be the certificate that was used to sign client.crt. If it is self-signed, it'll be client.crt itself (client.crt will be twice in a row).
If you're getting error 20 specifically and your client certificate is self-signed, you might have encountered this bug. To fix it you should either drop keyUsage from your certificate entirely or add keyCertSign to the list. To verify whether you've stumbled upon it, check whether Key Usage is listed in X509v3 extensions: section in the output of the following command:
openssl x509 -in client.crt -text -noout
The certificate I used to sign another one was not CA so it simply could not be verified, so that's why I had this error from openssl verify command:
error 20 at 0 depth lookup:unable to get local issuer certificate
If you're not CA then obviously there's nothing you can do about it.
ccs received early
Looks like a fallout from fixes for CVE-2014-0224. Since patches seems to be available check that your system is up-to-date or report the bug to your distributor.
More details might be available if you would add information about the server system you are running, especially which OS, which version of OpenSSL and which patches.
In my case I mistakenly downloaded 'cloudflare.crt' file from digital ocean's website which has older certificate and that wasted quite a bit of my time.
As their tutorial shows up in the google search.
wrong certificate from digital ocean
link to correct certificate
I have A nice working way. First before Creating pointing domain i.e
server_name api.example.com;
location / {
proxy_pass "http://example.com:9191";
}
create a sub domain of api.domain.com in your cpanel then now locate your crt files here
/var/cpanel/ssl/apache_tls/api.domain.com
you will find combined file done now put combine file i.e
ssl_certificate /var/cpanel/ssl/apache_tls/api.domain.com/combined;
then ssl you will find it under cpanel ssl/tsl->install ssl
You can locate where your ssl file are via google
your end ssl configuration will be like this
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name api.example.com;
location / {
proxy_pass "http://example.com:9191";
}
location /socket.io/ {
proxy_pass "http://example.com:9191";
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
}
location /engine.io/ {
proxy_pass "http://example.com:9191";
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
}
ssl_certificate /var/cpanel/ssl/apache_tls/api.domain.com/combined;
ssl_certificate_key /var/cpanel/ssl/system/certs/crashgame/private.key;
}
Please have your Private key in path where you can locate

Some clients accept SSL cert; others reject it

Some HTTP clients accept this certificate, and others do not. What could make the difference?
Java rejects it.
((javax.net.ssl.HttpsURLConnection)new java.net.URL("https://www.lucidpress.com")
.openConnection())
.getInputStream()
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject
alternative DNS name matching www.lucidpress.com found. at
sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at
sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1715) at
sun.security.ssl.Handshaker.fatalSE(Handshaker.java:257) at
sun.security.ssl.Handshaker.fatalSE(Handshaker.java:251) at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1168)
at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:609) at
sun.security.ssl.Handshaker.process_record(Handshaker.java:545) at
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:963) at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1208)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1235)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1219)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
Python requests rejects it.
import requests
requests.get('https://www.lucidpress.com')
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 55, in get
return request('get', url, **kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 44, in request
return session.request(method=method, url=url, **kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 456, in request
resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 559, in send
r = adapter.send(request, **kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 382, in send
raise SSLError(e, request=request) requests.exceptions.SSLError: hostname 'www.lucidpress.com' doesn't match either of '*.lucidchart.com', 'lucidchart.com'
cURL accepts it.
$ curl -v https://www.lucidpress.com
About to connect() to www.lucidpress.com port 443 (#0)
Trying 54.236.129.63... connected
successfully set certificate verify locations:
CAfile: none CApath: /etc/ssl/certs
SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server key exchange (12):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using DHE-RSA-AES256-SHA
Server certificate:
subject: OU=Domain Control Validated; CN=*.lucidpress.com
start date: 2014-05-12 16:20:34 GMT
expire date: 2015-07-09 22:19:45 GMT
subjectAltName: www.lucidpress.com matched
issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure
Certificate Authority - G2
SSL certificate verify ok.
wget rejects it.
wget https://www.lucidpress.com
--2014-08-09 19:55:41-- https://www.lucidpress.com/ Resolving www.lucidpress.com (www.lucidpress.com)... 107.23.98.6, 54.236.129.63,
54.88.154.168 Connecting to www.lucidpress.com (www.lucidpress.com)|107.23.98.6|:443... connected. ERROR: no
certificate subject alternative name matches requested host name
'www.lucidpress.com'. To connect to www.lucidpress.com insecurely, use
'--no-check-certificate'.
Chrome, FF, and IE accept it.
Why is the behavior different?
Some HTTP clients accept this certificate, and others do not. What could make the difference?
The short answer: load balancing, virtual hosting and SNI.
The long answer... first, here's an analysis of the certificate. We need to go though this to ensure there's no obvious mistakes.
From the dump below, there's a wildcard DNS name in the Common Name. Placing a DNS name in the CN is deprecated by both the IETF and the CA/Browser Forums. A "friendly name" should be placed in the CN because its displayed to the user. While its deprecated, its not forbidden.
Instead, DNS names should go in the Subject Alternate Name. There should be two of them. The first would be lucidpress.com and the second would be *.lucidpress.com. You need just lucidpress.com because the wildcard needs to match a label.
For reference, the IETF deprecates a DNS name in the CN in RFC 6125 Section 3.1 Server Identity; and Section 6.4.4 Checking of Common Names.
The CA/Browser Forums deprecates a DNS name in the CN in Baseline Requirements (BR) Section 9.2.2 Subject Common Name Field. Also, according to the CA/B, the Subject Alternate Name is required. See Section 9.2.1 Subject Alternative Name Extension.
Related: RFC 6125, Section 6.4.3, also does not allow the matching of *.lucidpress.com to lucidpress.com. The CA/B BR covers wildcards in Section 11.1.3, but it does not discuss matching rules.
With the background information above and the certificate below, here's what is going on.
You have 2 names in the default certificate. Its served by default by Apache because its the first virtual host in the configuration file.
lucidchart.com
*.lucidchart.com
You have 2 names in the Lucid Press' certificate.
lucidpress.com
*.lucidpress.com
I think the difference is Server Name Indication (SNI). Its a TLS extension, so you need TLS 1.0 or above. Those that have no trouble get the Lucid Press certifcate and use TLS 1.0 or above with SNI; those that have trouble get the default certificate and use SSLv3 or no SNI. Windows XP will use TLS 1.0 but not SNI, so its experienced often in the field due to the deployment base.
The browsers accept it because they are using TLS 1.0 or above and sending the SNI extension. Because SNI allows your Apache server to select the proper certificate during the handshake, there are no name matching problems.
Java rejects it because it uses SSLv3, even when you say SSLContext.getInstance("TLS");. You have to jump through some hoops to ensure you really get TLS 1.0 and above. There's a few questions on Stack Overflow about it. See, for example, Which Cipher Suites to enable for SSL Socket?.
Python rejects it because I'm guessing you are using 2.x, or you are allowing SSLv3. You need 3.0 or above to get SNI. See Python 3 Support? on the Python FAQ.
wget added support for SNI in version 1.14. I suspect wget is not enabling its or using SSLv3.
cURL likely ensures SNI is used if available. Daniel is very thorough, and he tries to ensure a trouble free experience and secure posture out of the box.
In the OpenSSL dump, the options of interest are -tls1 -servername. You can get TLS without SNI by omitting -servername. So 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://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
Validity
Not Before: May 12 16:20:34 2014 GMT
Not After : Jul 9 22:19:45 2015 GMT
Subject: OU=Domain Control Validated, CN=*.lucidpress.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:e0:f6:77:03:c9:5e:cb:51:e3:d3:7a:b6:60:
d9:3d:60:26:9c:4b:00:c5:cb:b1:55:2e:d9:ee:f5:
08:8d:b7:64:e9:31:2e:83:e4:24:f3:89:4e:46:87:
b8:55:b6:34:0a:c9:3b:55:08:10:77:13:7e:85:d6:
8c:fa:06:dd:c1:7f:fa:9e:13:c8:1a:d8:36:22:3c:
cb:16:9f:cb:c7:5b:7c:7c:0b:6d:c3:ef:24:45:15:
5a:7a:38:dd:df:83:eb:c3:ea:9b:57:d5:8f:d8:6c:
ff:33:4a:21:02:2a:92:9a:e0:5d:58:51:75:07:b6:
ad:21:8c:34:91:20:f5:00:9e:f6:dd:90:7e:a8:60:
0e:14:73:de:90:a1:f4:29:83:a0:d8:9d:29:e5:de:
c5:cb:b5:36:84:ba:30:d4:a9:9f:b9:bf:89:26:e5:
80:5a:f6:3b:27:cc:6d:3f:31:1e:cc:51:09:12:73:
a6:de:da:b9:a4:19:86:68:7f:e6:2b:c7:3b:a6:ce:
6a:5a:dd:c9:ac:61:18:80:f5:d4:f1:6a:70:2c:9f:
8f:af:a6:c5:1d:78:97:97:90:92:6c:21:61:39:ce:
f8:c9:99:e2:02:b5:ce:ba:dc:f4:46:ba:e3:1f:ec:
ce:a5:e4:6b:56:1e:e6:20:89:44:7b:2c:9f:3a:c4:
33:f1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.godaddy.com/gdig2s1-59.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114413.1.7.23.1
CPS: http://certificates.godaddy.com/repository/
Authority Information Access:
OCSP - URI:http://ocsp.godaddy.com/
CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt
X509v3 Authority Key Identifier:
keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
X509v3 Subject Alternative Name:
DNS:*.lucidpress.com, DNS:lucidpress.com
X509v3 Subject Key Identifier:
CA:97:CC:32:09:20:3E:5F:23:05:4C:DD:F2:DA:4B:1C:E5:02:E8:69
Signature Algorithm: sha256WithRSAEncryption
4e:0c:8e:af:d5:c7:06:9e:b9:2c:36:97:d0:9e:1c:84:e8:e1:
69:5a:36:a3:4f:9f:81:c9:78:5d:ca:35:df:63:be:23:88:4c:
ba:eb:17:15:22:78:96:5d:5f:dc:3b:fa:cf:14:b6:e9:3a:fe:
28:19:1c:85:d2:1b:23:b3:79:6d:b2:1d:76:6b:84:97:80:43:
1b:c0:b7:14:78:75:f9:47:31:6e:21:56:0d:5e:73:ed:d3:b2:
4b:ab:dc:b0:af:18:ee:2d:bb:65:ff:c7:cb:ff:53:64:8f:a5:
e8:aa:45:da:fc:0f:b5:8f:da:0f:3e:b1:3b:d0:47:49:52:af:
8d:f7:a3:42:3b:d3:a1:f4:a1:22:d5:fe:2f:4c:59:b4:18:3f:
62:1e:4e:56:65:9b:2b:d6:76:cd:29:74:d6:74:a4:7b:bb:6f:
b2:1d:45:12:67:14:b3:06:a7:36:ee:3a:48:d1:d6:80:2b:fa:
6d:8b:64:01:0f:1e:51:48:0f:8b:e3:7d:13:86:79:a2:b2:04:
05:cb:8d:07:35:d9:fa:7e:6d:5d:42:c0:a5:f4:b2:8e:57:53:
24:b3:aa:e6:92:b1:70:07:73:98:00:91:9b:0f:3e:6e:fe:1d:
78:7c:57:68:47:d7:8e:6f:1a:64:26:7b:69:f5:b1:13:c2:71:
2d:ac:56:b6
$ 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#53(172.16.1.10)
;; WHEN: Sun Aug 10 00:02:52 EDT 2014
;; MSG SIZE rcvd: 160
$ dig www.lucidpress.com
; <<>> DiG 9.8.5-P1 <<>> www.lucidpress.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34260
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.lucidpress.com. IN A
;; ANSWER SECTION:
www.lucidpress.com. 599 IN CNAME chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com.
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 54.88.154.168
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 107.23.98.6
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 54.236.129.63
;; Query time: 48 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Sun Aug 10 00:02:38 EDT 2014
;; MSG SIZE rcvd: 160
If interested, 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