Multi-domain SAN certificate throwing 'unable to verify the first certificate' error - ssl

I have a self-signed multi-domain SAN certificate as below :
$ openssl x509 -in trustedCertificates.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d0:6e:6b:66:c6:55:44:09
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=WA, L=Seattle, O=MyOrg, OU=MyDept, CN=*.us-west-2.compute.internal
Validity
Not Before: Mar 23 22:15:10 2018 GMT
Not After : Mar 23 22:15:10 2019 GMT
Subject: C=US, ST=WA, L=Seattle, O=MyOrg, OU=MyDept, CN=*.us-west-2.compute.internal
Subject Public Key Info:
...
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:*.us-west-2.compute.amazonaws.com
Signature Algorithm: sha256WithRSAEncryption
...
...
I use this certificate to configure+enable SSL on presto server. Further, I import this certificate in the java truststore of the presto-cli client machine (in my case, both are on same host). However, when I connect to the presto-server, I keep getting the below error message even though I do use a FQDN that matches the CN in the certificate :
$ presto-cli --server https://ip-xxx-xx-xx-xxx.us-west-2.compute.internal:8446 --catalog hive --schema default --debug --user Administrator --password
Password:
presto:default> show schemas;
Error running command: javax.net.ssl.SSLPeerUnverifiedException: Hostname ip-xxx-xx-xx-xxx.us-west-2.compute.internal not verified:
certificate: sha256/zN/GPT/AWTkUAEpAGhhSTvQAmIYPRmLBxvBU6oJDQfM=
DN: CN=*.us-west-2.compute.internal, OU=MyDept, O=MyOrg, L=Seattle, ST=WA, C=US
subjectAltNames: [*.us-west-2.compute.amazonaws.com]
...
...
at com.facebook.presto.cli.Presto.main(Presto.java:32)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: Hostname ip-xxx-xx-xx-xxx.us-west-2.compute.internal not verified:
certificate: sha256/zN/GPT/AWTkUAEpAGhhSTvQAmIYPRmLBxvBU6oJDQfM=
DN: CN=*.us-west-2.compute.internal, OU=MyDept, O=MyOrg, L=Seattle, ST=WA, C=US
subjectAltNames: [*.us-west-2.compute.amazonaws.com]
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:308)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:268)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:160)
at
...
...
com.facebook.presto.client.JsonResponse.execute(JsonResponse.java:130)
... 7 more
When I do a connection check, I see this error :
$ openssl s_client -connect ip-xxx-xx-xx-xxx.us-west-2.compute.internal:8446
CONNECTED(00000003)
depth=0 C = US, ST = WA, L = Seattle, O = MyOrg, OU = MyDept, CN = *.us-west-2.compute.internal
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = WA, L = Seattle, O = MyOrg, OU = MyDept, CN = *.us-west-2.compute.internal
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=WA/L=Seattle/O=MyOrg/OU=MyDept/CN=*.us-west-2.compute.internal
i:/C=US/ST=WA/L=Seattle/O=MyOrg/OU=MyDept/CN=*.us-west-2.compute.internal
---
Server certificate
-----BEGIN CERTIFICATE-----
...
...
If I use a certificate with only single domain CN=*.us-west-2.compute.internal without any SAN extension, everything seem to be working fine. Any ideas on what's going wrong here?

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

Python ssl: IP address in check_hostname

Can Python3 ssl library work with IP addresses, not hostnames in the certificate?
Let's suppose I try to connect to a server:
ip = '192.168.0.99'
context = ssl.create_default_context(cafile='ca.crt')
with socket.create_connection((ip, 443)) as sock:
with context.wrap_socket(sock, server_hostname=ip) as ssock:
print(ssock.version())
When I run it, I get an error:
SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)
IP address 192.168.0.99 is written into certificate Common Name and into Subject Alt Name too.
$ openssl x509 -in san.crt -noout -text | grep -B 1 192.168.0.99
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = RU, ST = MSK, O = Internet Widgits Pty Ltd, OU = example, CN = 192.168.0.99
--
Not After : Jul 4 21:31:32 2030 GMT
Subject: C = RU, ST = MSK, O = Internet Widgits Pty Ltd, OU = example, CN = 192.168.0.99
--
X509v3 Subject Alternative Name:
IP Address:192.168.0.99
SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)
The error is not about the hostname not matching the certificate but about the inability to find a locally trusted issuer for the certificate.
context = ssl.create_default_context(cafile='ca.crt')
I assume your intention is that ca.crt is the issuer for san.crt. But according to what you show from the certificate it looks like a self-signed certificate instead (subject and issuer is the same) and not signed by ca.crt.

How to properly submit certificate for signing in Kubernetes?

I'm trying to get a certificate signed by the Kubernetes CA (1.11) by submitting the following:
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
name: openunison.openunison.svc.cluster.local
spec:
groups:
- system:authenticated
request: LS0tLS1CRUdJTiBORVcgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCk1JSURCakNDQWU0Q0FRQXdnWkF4Q3pBSkJnTlZCQVlUQW5Wek1SRXdEd1lEVlFRSUV3aDJhWEpuYVc1cFlURVQKTUJFR0ExVUVCeE1LWVd4bGVHRnVaSEpwWVRFWk1CY0dBMVVFQ2hNUWRISmxiVzlzYnlCelpXTjFjbWwwZVRFTQpNQW9HQTFVRUN4TURhemh6TVRBd0xnWURWUVFERXlkdmNHVnVkVzVwYzI5dUxtOXdaVzUxYm1semIyNHVjM1pqCkxtTnNkWE4wWlhJdWJHOWpZV3d3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ3gKRnpBR2tBWlYrZWxxem1aK3RxUW1xTEsxV3kvRFRXU0FZT3N2Mk9SaDFyVEx4eTZ6NVRwVW9kNzBjYmhCQlowbgptMDMzd0VkWW1QODFHRVM1YlYyQkpQa2FiN1EySmltQXFuU1MrcHYvSmVjTnVUcGlUb05xVUlGeHhUcXdlWHo3CkgxUVBPY25LZ251M0piempKUXZBbWZoUXZaNjdHRXRGanl3QXE5MS9TUFBHdVVlUFBOb09kU1J0MHlJdFJSV1cKV0N4THhLRW4zUU5jc1hqZWtJUy9aMXdTdERuVyttQi9LZERWbmlZUzlYRlV1T3BTcEl4ZkhHNmFkdTdZaUNLZgptQWZqSE1jdmlOQlN3M3ZBOGQ4c21yVnZveHhkelpzMGFXRlpZai9mQ0IycVVRb2FXQi85TmU1SStEb3JBbXJXCm42OGtoY1MwbkxsWGFIQmhLZjM1QWdNQkFBR2dNREF1QmdrcWhraUc5dzBCQ1E0eElUQWZNQjBHQTFVZERnUVcKQkJTUExoa2V5eUkrQmttSXEzdmxpalA4MHI1RXVUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFpMndVUjA4RgpjL3VVanovWHVvd29vQ1M3c2tndlpSZDVhVTFxdzU2MzdmOGVJSmM2S0huNGNZZUw3YTZ5M3M0QmJnYVVIOVpVCm5Sb3N1V1R2WEJNTUxxLzJBSEx4VVhsTGNhZW03cE1EbXEzbGkxNEkvWTdQWUlxSFQxNEc2UnlkQUUvc2R6MHUKd1RNL0k3eHJ0bFZNTzliNXpuWnlxVkpTY0xhYnRDTXMwa3dwQlpVM2dTZThhWW8zK3A3d2pVeVpuZmFoNllhNAovcXZVd3kzNGdianZSTWc2NmI3UTl2dERmU0RtUWFyVVh0QVJEd052T1lnNmpIMkpwYmUvNUdqcHhaUTRYYW93CnZodGJyY2NTL2RCbFZwWlQxd0k2Um85WFl2OEliMm1icWhFMjBNWGJuVWUrYS9uUkdPVndMaVRQMGNnSk92eDIKdzRZWmtxSUhVQWZad0E9PQotLS0tLUVORCBORVcgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==
usages:
- digital signature
- key encipherment
- server auth
The response complains that its not PEM - The CertificateSigningRequest "openunison.openunison.svc.cluster.local" is invalid: spec.request: Invalid value: []byte{0x2d,...}: PEM block type must be CERTIFICATE REQUEST, however, the CSR is a valid CSR:
echo 'LS0tLS1CRUdJTiBORVcgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCk1JSURCakNDQWU0Q0FRQXdnWkF4Q3pBSkJnTlZCQVlUQW5Wek1SRXdEd1lEVlFRSUV3aDJhWEpuYVc1cFlURVQKTUJFR0ExVUVCeE1LWVd4bGVHRnVaSEpwWVRFWk1CY0dBMVVFQ2hNUWRISmxiVzlzYnlCelpXTjFjbWwwZVRFTQpNQW9HQTFVRUN4TURhemh6TVRBd0xnWURWUVFERXlkdmNHVnVkVzVwYzI5dUxtOXdaVzUxYm1semIyNHVjM1pqCkxtTnNkWE4wWlhJdWJHOWpZV3d3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ3gKRnpBR2tBWlYrZWxxem1aK3RxUW1xTEsxV3kvRFRXU0FZT3N2Mk9SaDFyVEx4eTZ6NVRwVW9kNzBjYmhCQlowbgptMDMzd0VkWW1QODFHRVM1YlYyQkpQa2FiN1EySmltQXFuU1MrcHYvSmVjTnVUcGlUb05xVUlGeHhUcXdlWHo3CkgxUVBPY25LZ251M0piempKUXZBbWZoUXZaNjdHRXRGanl3QXE5MS9TUFBHdVVlUFBOb09kU1J0MHlJdFJSV1cKV0N4THhLRW4zUU5jc1hqZWtJUy9aMXdTdERuVyttQi9LZERWbmlZUzlYRlV1T3BTcEl4ZkhHNmFkdTdZaUNLZgptQWZqSE1jdmlOQlN3M3ZBOGQ4c21yVnZveHhkelpzMGFXRlpZai9mQ0IycVVRb2FXQi85TmU1SStEb3JBbXJXCm42OGtoY1MwbkxsWGFIQmhLZjM1QWdNQkFBR2dNREF1QmdrcWhraUc5dzBCQ1E0eElUQWZNQjBHQTFVZERnUVcKQkJTUExoa2V5eUkrQmttSXEzdmxpalA4MHI1RXVUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFpMndVUjA4RgpjL3VVanovWHVvd29vQ1M3c2tndlpSZDVhVTFxdzU2MzdmOGVJSmM2S0huNGNZZUw3YTZ5M3M0QmJnYVVIOVpVCm5Sb3N1V1R2WEJNTUxxLzJBSEx4VVhsTGNhZW03cE1EbXEzbGkxNEkvWTdQWUlxSFQxNEc2UnlkQUUvc2R6MHUKd1RNL0k3eHJ0bFZNTzliNXpuWnlxVkpTY0xhYnRDTXMwa3dwQlpVM2dTZThhWW8zK3A3d2pVeVpuZmFoNllhNAovcXZVd3kzNGdianZSTWc2NmI3UTl2dERmU0RtUWFyVVh0QVJEd052T1lnNmpIMkpwYmUvNUdqcHhaUTRYYW93CnZodGJyY2NTL2RCbFZwWlQxd0k2Um85WFl2OEliMm1icWhFMjBNWGJuVWUrYS9uUkdPVndMaVRQMGNnSk92eDIKdzRZWmtxSUhVQWZad0E9PQotLS0tLUVORCBORVcgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==' | base64 -d | openssl req -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = us, ST = virginia, L = alexandria, O = tremolo security, OU = k8s, CN = openunison.openunison.svc.cluster.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
What am I missing?
You are submitting it correctly, but the Kubernetes certificate manager doesn't like the format of your CSR header:
-----BEGIN NEW CERTIFICATE REQUEST----- nor the ending
-----END NEW CERTIFICATE REQUEST-----.
However, it does like:
-----BEGIN CERTIFICATE REQUEST----- and
-----END CERTIFICATE REQUEST-----
you can modify those two lines and it should work (I tried it myself).
Opened this to address the problem.

Does openssl refuse self signed certificates without basic constraints?

I have two extremely similar self signed certificates, generated via two different methods.
To test them I have:
Added an entry in my hosts file for local.mydomain.com
Set up an nginx server to listen on that domain on port 443 with the certificate under test plus associated private key (I then switch the cert and restart nginx to compare)
Connected to nginx with openssl s_client -connect local.mydomain.com -CAfile /path/to/the/ca/cert.pem
One certificate fails:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = local.mydomain.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=local.mydomain.com
i:/CN=local.mydomain.com
---
One certificate succeeds:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify return:1
---
Certificate chain
0 s:/CN = local.mydomain.com
i:/CN = local.mydomain.com
---
I compare the details of the certificates with openssl x509 -in /path/to/the/ca/cert.pem -text -noout
The failing cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
47:dc:02:c7:11:fc:8e:96:45:22:aa:6b:23:79:32:ca
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 18 11:55:31 2016 GMT
Not After : Nov 18 12:15:31 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
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 Subject Alternative Name:
DNS:local.mydomain.com
X509v3 Subject Key Identifier:
6D:4F:AF:E4:60:23:72:E5:83:27:91:7D:1D:5F:E9:7C:D9:B6:00:2A
Signature Algorithm: sha256WithRSAEncryption
<stuff>
The working cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:6b:3d:a3:b9:a3:a4:b4
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 19 13:27:30 2016 GMT
Not After : Nov 19 13:27:30 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Authority Key Identifier:
keyid:03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
57<stuff>
Looking at this the most obvious difference is that the working cert has CA:TRUE under X509v3 Basic Constraints. However, from reading around the web I was under the impression that self signed certs weren't meant to be CAs, in particular this says they normally won't be:
https://security.stackexchange.com/questions/44340/basic-self-signed-certificate-questions
The answer there says that being self-signed there is no CA involved. But maybe openssl requires self signed certs to have that set anyway?
From my own experiments I can confirm what you see. My explanation of the behavior is that a self signed certificate is still a certificate which is signed by the issuer, even if the issuer's certificate is the certificate itself. But only CA certificates can be used to sign certificates, i.e. that's exactly the constraint CA:true allows. This means that a self-signed certificate needs also to be a CA certificate with the constraint CA:true.
RFC5280 says:
So, if your certificate does not have CA:TRUE flag, this certificate may not be used to verify the signature on any certificate, including itself. OpenSSL correctly follows the RFC.
It is incorrect to think that a certificate belongs to one of two types, either "CA certificate" or "end-entity certificate". A certificate with CA:TRUE can be used for authenticating the entity. This is exactly what you do when you authenticate with a self-signed certificate. It can also be a certificate with CA:TRUE, signed by someone else.

SSL Error showing only from mobile device

I am using a PositiveSSL certificate for my website www.movielee.com
Whenever I browse from my samsung S5 device,it shows
the security certificate of this site is expired
But never faced any kind of errors while browsing from PC.
Is that an issue with the intermediate certificate?
My browser and phone's time date settings are ok.
Using shared cPanel for the website.If there is a solution to get rid of this for shared hostings managed by cPanel,please let me know.
I am using a PositiveSSL certificate for my website
www.movielee.com Whenever I browse from my samsung S5 device,it shows
the security certificate of this site is expired
It appears the certificate is valid (see below). Make sure your Samsung's clock is set correctly.
Also make sure the CRLs associated with the certificate (and its chain) are valid. It looks like a new CRL was published around the time you asked the question:
$ curl http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl | \
openssl crl -inform DER -text -noout
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 139k 100 139k 0 0 661k 0 --:--:-- --:--:-- --:--:-- 795k
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Last Update: Aug 25 00:39:57 2014 GMT
Next Update: Aug 29 00:39:57 2014 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:90:AF:6A:3A:94:5A:0B:D8:90:EA:12:56:73:DF:43:B4:3A:28:DA:E7
X509v3 CRL Number:
199
Revoked Certificates:
Serial Number: 07C977601B68FB2A2A061C2491521E5C
Revocation Date: Feb 20 19:10:49 2014 GMT
...
$ openssl s_client -connect www.movielee.com:443 | \
openssl x509 -text -noout
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e6:c8:59:6a:3b:28:2c:ff:af:4c:82:ad:b6:61:d1:2f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Validity
Not Before: Aug 14 00:00:00 2014 GMT
Not After : Aug 14 23:59:59 2015 GMT
Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=movielee.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d2:ca:25:8f:bb:f2:35:a1:12:a0:af:f7:f6:ef:
39:32:4e:e5:21:32:6d:d0:9a:fc:1f:f1:df:0d:eb:
78:65:11:81:57:9b:75:cb:e0:45:2c:d8:55:2f:5e:
f3:5e:42:b2:49:99:bb:90:8b:59:15:de:fa:14:9b:
cd:b9:d2:48:27:9c:6e:df:fe:16:76:26:d3:ed:f8:
63:37:53:47:14:92:51:96:5c:e0:5d:b3:33:71:af:
47:b6:45:8b:26:e4:99:b8:ea:1b:41:78:92:f2:ec:
c6:4e:87:c5:3c:26:31:1f:b6:d9:32:28:39:31:4b:
24:81:61:e2:1a:89:df:e5:cf:04:3a:d8:25:fd:2e:
00:77:99:95:16:77:a7:b9:cb:b4:67:2e:21:4a:48:
98:49:a8:7d:52:3d:48:a3:a0:46:c9:dd:34:72:57:
e3:50:49:cb:66:6f:fb:73:39:71:7f:cd:a7:73:56:
4e:87:1f:55:e9:a4:ab:7b:5e:69:78:1a:ba:8b:a1:
c9:df:f5:36:51:2d:f9:ba:a1:6d:51:4d:ce:b7:94:
43:6b:0b:8e:7e:cd:47:a9:2d:ff:fa:0f:c5:c2:f6:
09:cd:99:3a:a0:e0:5e:ed:e0:6c:7a:bf:5f:d1:46:
0b:c1:9f:80:2e:6b:bc:37:61:c9:23:4f:df:57:a4:
f2:ff
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:90:AF:6A:3A:94:5A:0B:D8:90:EA:12:56:73:DF:43:B4:3A:28:DA:E7
X509v3 Subject Key Identifier:
8E:9E:11:F1:21:88:CF:0F:01:80:3B:A4:60:76:B0:76:B1:B6:CA:19
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
CPS: https://secure.comodo.net/CPS
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/COMODORSADomainValidationSecureServerCA.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:movielee.com, DNS:www.movielee.com
Signature Algorithm: sha256WithRSAEncryption
8b:41:bf:20:da:b5:6a:8e:e9:88:a9:e2:3e:95:05:26:74:40:
8b:38:1e:3d:be:14:19:5c:38:dc:30:87:94:77:0c:85:8f:7e:
f3:a6:da:b5:3f:8f:2c:e5:90:bd:e4:f0:6a:20:22:98:6f:f7:
22:f8:3c:02:25:6b:a0:b6:9d:eb:1a:b2:a1:17:e5:67:2b:2a:
44:6f:37:70:59:a3:6f:9f:a7:32:50:49:ec:83:c0:4a:eb:65:
c0:c3:a8:36:42:d1:59:0a:3e:d0:1d:36:d4:75:92:0b:2b:ed:
a1:31:ca:b8:03:2b:44:91:e6:b2:7f:7b:01:dc:aa:c4:1d:cf:
a0:d4:c8:da:c7:d2:de:d7:4e:de:49:1f:86:87:c7:5b:1d:ed:
7f:dd:d0:c5:b2:16:fc:2c:54:13:5d:8e:02:e8:4c:c6:d1:1c:
46:f4:a1:6d:fc:75:d8:fc:0d:28:f2:3d:6d:ab:e5:f3:5f:56:
25:8b:9a:21:7a:46:b8:a9:eb:c9:a7:aa:30:a1:14:ec:be:65:
af:f7:40:bb:5b:a8:f5:31:e3:24:d0:a7:be:22:dd:a6:52:d0:
9f:30:56:9a:d8:d5:b2:f8:8b:ef:57:da:b4:e8:93:6b:67:25:
27:a7:9c:8b:c2:32:46:b0:de:46:67:13:b2:05:9b:be:e7:9b:
02:9f:22:f6