In SSL how a certificate is matched/found in truststore? - ssl

In SSL how does it check whether there is a matching certificate in the trust-store? Is it by matching the fingerprint or the serial number?
I always thought it's by matching the fingerprint, but when I ran a java SSL debug following is what I got, and I couldn't see any fingerprint there.
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=XXXX
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 1024 bits
modulus: XXXX
public exponent: XXXX
Validity: [From: Mon Mar 16 22:48:10 UTC 2015,
To: Sun Jun 14 22:48:10 UTC 2015]
Issuer: CN=XXXX
SerialNumber: [ XXXXXXX]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
...
]
]
]
Algorithm: [SHA256withRSA]
Signature:
...
]
***
I hope this is not a duplicate question (I checked the suggested questions before posting).

It doesn't check whether there is a matching certificate. It checks whether there is a certificate whose subject equals the issuer of this certificate, and whose public key verifies the signature of this certificate.

Quite often, the Certificate Authority Key Identifier is marked as non-critical when present in the certificate to verify, and it's not even always present. You couldn't really rely on that as a fingerprint reference to use.
The verification is done by building a certification path, by chaining the Issuer DN (Distinguished Name) of the certificate to verify to the Subject DN of a CA certificate you trust.
This is described in the CertPathBuilder/CertPathValidator sections of the Java PKI Programmer's Guide. (More generally, this follows RFC 3820, since there are other attributes to check too.)
Alternatively, you can also have an exact End Entity Certificate (not a CA certificate) directly in the truststore. In this case, an exact match with the certificate can be used.

Related

Common Name Invalid Error for SSL Certificate [duplicate]

This question already has answers here:
Invalid self signed SSL cert - "Subject Alternative Name Missing"
(11 answers)
Getting net::ERR_CERT_COMMON_NAME_INVALID
(2 answers)
NET::ERR_CERT_COMMON_NAME_INVALID - Error Message
(3 answers)
Closed 11 months ago.
I have a certificate for a Synology NAS (Common Name: nas1.contoso.local) signed by a Windows 2016 CA server. Unfortunately, I am getting a NET::ERR_CERT_COMMON_NAME_INVALID error when I open the site (https://nas1.contoso.local) in Google Chrome.
However, the URL is exactly the same as the certificate common name, so I'm not sure the issue would be?
The root certificate for the CA server is already trusted by my computer and there is a "This certificate is valid" message in the certificate details. I've also tried opening the site in Safari, and the certificate details has the error "nas1.contoso.local certificate name does not match input".
Common Name: nas1.contoso.local
Site URL (with the error): https://nas1.contoso.local
Certificate Expires: March 20, 2024 11:52:02AM PST
Encryption: 2056
I've also tried creating and using certificates for *.contoso.local, as well as another nas1.contoso.local certificate with an IP address SAN. The wildcard certificate failed the same way, but oddly enough, the direct IP address SAN worked without any certificate errors when going directly to the IP address (e.g. https://10.0.0.2), but going directly to nas1.contoso.local still threw an error.
I'm not sure what could be causing this problem? Any help would be appreciated.
Edit: Here's the output from echo | openssl s_client -connect nas1.contoso.local:443 | openssl x509 -text -noout (removed the modulus and exponent output)
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1e:00:00:00:4b:5f:ad:53:57:8f:69:f5:c1:00:00:00:00:00:4b
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=contoso-WIN-T2A-CA
Validity
Not Before: Mar 21 18:52:02 2022 GMT
Not After : Mar 20 18:52:02 2024 GMT
Subject: C=US, ST=CA, O=contoso, OU=IT, CN=nas1.contoso.local/emailAddress=admin#contoso.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
X509v3 extensions:
1.3.6.1.4.1.311.20.2:
...W.e.b.S.e.r.v.e.r
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Subject Key Identifier:
66:2F:78:AC:17:69:25:8F:68:7A:BD:4B:CF:6A:C8:95:FE:8C:26:E1
X509v3 Authority Key Identifier:
keyid:58:66:30:49:C8:5C:A2:9B:E9:BE:B5:DE:7C:7B:ED:F7:3E:8F:43:48
X509v3 CRL Distribution Points:
Full Name:
URI:http://WIN-T2A/CertEnroll/contoso-WIN-T2A-CA.crl
Authority Information Access:
CA Issuers - URI:ldap:///CN=contoso-WIN-T2A-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=local?cACertificate?base?objectClass=certificationAuthority
Signature Algorithm: sha256WithRSAEncryption

Cannot extract certificate organization on some urls

I want to be able to look up a website and provide the registered organization for that website.
For example get_company("google.com") -> Google LLC. However, some websites that are signed and display their certificates correctly when opened in chrome don't work. For example "microsoft.com" is one that doesn't work. How can I look those other ones up?
import ssl
import socket
import OpenSSL
def get_certificate(host, port=443, timeout=10):
context = ssl.create_default_context()
conn = socket.create_connection((host, port))
sock = context.wrap_socket(conn, server_hostname=host)
sock.settimeout(timeout)
try:
der_cert = sock.getpeercert(True)
finally:
sock.close()
return ssl.DER_cert_to_PEM_cert(der_cert)
def get_company(url):
certificate = get_certificate(url)
x509 = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, certificate)
return dict(x509.get_subject().get_components())[b'O']
EDIT:
Just to clarify, I am not interested in certificates made by Authorities like Let's Encrypt and I can filter them. They are unrelated to the question. The specific example I posted was because when I go to microsoft.com in Google Chrome I can see the subject field contains the organization.
There are multiple validation types of X.509 certificates. Those specify which informations are part of the certificate (and thus validated by the CA issuing the certificate).
Domain Validated (DV): The subject of those certificates contains exactly one value: The domain. Those are very common these days, since that's what you get from Let's Encrypt
Organization Validated (OV): In addition to the domain, the certificate's subject also contains information about the certificate's owner. Usually just an organization name, sometimes also an actualy name or an organizational unit (OU).
The certificate you have problem with, is probably a DV certificate which simply does not have any organization information in its subject (which you are trying to parse).
The certificate currently used on microsoft.com is:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
78:00:0f:e6:92:e4:bd:9e:fe:63:c5:71:67:00:00:00:0f:e6:92
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=Microsoft IT TLS CA 4
Validity
Not Before: Feb 5 20:30:44 2020 GMT
Not After : Feb 5 20:30:44 2022 GMT
Subject: CN=microsoft.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:f1:1c:98:26:23:0f:fe:d2:ab:5d:a0:81:07:06:
ed:48:49:1b:8e:56:04:bb:de:80:df:06:6f:5a:5a:
96:3d:80:1e:3b:7a:aa:9d:c7:43:a0:fa:75:89:a9:
38:3c:20:52:cd:43:47:32:43:eb:ad:e7:50:37:b1:
3a:53:d1:2d:54:b2:4d:f4:1f:fb:16:ab:bb:50:53:
d5:b2:71:2b:a9:0c:fa:77:45:a6:fe:62:74:e1:e3:
cd:28:17:52:5c:4c:45:0d:7e:65:f8:44:9e:0f:9e:
34:1c:5d:e8:f0:b2:4f:1c:2c:9c:8b:a1:ae:74:a1:
1d:d8:2e:fb:10:3d:45:fd:02:cf:1f:d4:c8:8b:d5:
18:01:64:c0:ee:01:68:e0:db:da:79:5e:57:ff:a0:
a6:64:95:cf:68:4b:36:58:16:45:b0:0d:12:23:11:
e0:04:ae:e6:fc:5f:71:29:ff:60:9e:e4:6d:ef:e3:
2e:1d:28:e9:1c:23:8c:33:27:f4:33:f6:56:fb:f1:
b4:fc:55:96:61:0f:fe:a7:84:e7:c0:3b:84:0d:69:
ef:4c:da:83:05:08:81:68:97:d7:34:af:50:0b:78:
92:77:fe:8b:75:25:e5:57:51:bb:5a:25:2b:62:89:
da:83:69:d8:8f:ff:ce:cb:56:63:1f:2d:0f:23:48:
27:ad
Exponent: 65537 (0x10001)
X509v3 extensions:
S/MIME Capabilities:
......0...`.H.e...*0...`.H.e...-0...`.H.e....0...`.H.e....0...+....0
..*.H..
1.3.6.1.4.1.11129.2.4.2:
...i.g.u.......X......gp
.....p..w......F0D. $...Um...v......*2..>*./m\5.*3... v..^.|...$8.....P....b.e...UD....v."EE.YU$V.?./..m..#&c..K.]..\n......p..w......G0E. jFy............./9?4z..d....F....!..H..v.GN.........rc.....wb6...k..v.U.....6.J...W<S...8xp%../..........p..v......G0E.!..{r...GS7...[.....].~7.P...4..Ev. LzM...4
......yj+...
1.3.6.1.4.1.311.21.10:
0.0
..+.......0
..+.......
1.3.6.1.4.1.311.21.7:
0/.'+.....7.....u...........a...`.]...B...z..d...
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt
OCSP - URI:http://ocsp.msocsp.com
X509v3 Subject Key Identifier:
89:47:51:EA:1F:28:84:F0:D5:35:E4:97:C7:53:D6:82:D0:BE:C0:46
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Subject Alternative Name:
DNS:microsoft.com, DNS:s.microsoft.com, DNS:ga.microsoft.com, DNS:mi.microsoft.com, DNS:grv.microsoft.com, DNS:hup.microsoft.com, DNS:mac.microsoft.com, DNS:mkb.microsoft.com, DNS:pme.microsoft.com, DNS:pmi.microsoft.com, DNS:rss.microsoft.com, DNS:sar.microsoft.com, DNS:tco.microsoft.com, DNS:ieak.microsoft.com, DNS:mac2.microsoft.com, DNS:mcsp.microsoft.com, DNS:shop.microsoft.com, DNS:spur.microsoft.com, DNS:build.microsoft.com, DNS:itpro.microsoft.com, DNS:mango.microsoft.com, DNS:music.microsoft.com, DNS:pymes.microsoft.com, DNS:store.microsoft.com, DNS:aether.microsoft.com, DNS:alerts.microsoft.com, DNS:design.microsoft.com, DNS:garage.microsoft.com, DNS:gigjam.microsoft.com, DNS:ignite.microsoft.com, DNS:msctec.microsoft.com, DNS:online.microsoft.com, DNS:stream.microsoft.com, DNS:tpmsec.microsoft.com, DNS:afflink.microsoft.com, DNS:connect.microsoft.com, DNS:develop.microsoft.com, DNS:domains.microsoft.com, DNS:example.microsoft.com, DNS:madeira.microsoft.com, DNS:msdnisv.microsoft.com, DNS:mspress.microsoft.com, DNS:quantum.microsoft.com, DNS:sponsor.microsoft.com, DNS:wwwbeta.microsoft.com, DNS:business.microsoft.com, DNS:empresas.microsoft.com, DNS:learning.microsoft.com, DNS:msdnwiki.microsoft.com, DNS:pinpoint.microsoft.com, DNS:snackbox.microsoft.com, DNS:sponsors.microsoft.com, DNS:stationq.microsoft.com, DNS:aistories.microsoft.com, DNS:community.microsoft.com, DNS:crawlmsdn.microsoft.com, DNS:messenger.microsoft.com, DNS:minecraft.microsoft.com, DNS:backoffice.microsoft.com, DNS:enterprise.microsoft.com, DNS:iotcentral.microsoft.com, DNS:pinunblock.microsoft.com, DNS:reroute443.microsoft.com, DNS:communities.microsoft.com, DNS:explore-smb.microsoft.com, DNS:expressions.microsoft.com, DNS:ondernemers.microsoft.com, DNS:techacademy.microsoft.com, DNS:terraserver.microsoft.com, DNS:communities2.microsoft.com, DNS:connectevent.microsoft.com, DNS:dataplatform.microsoft.com, DNS:entrepreneur.microsoft.com, DNS:hxd.research.microsoft.com, DNS:mspartnerira.microsoft.com, DNS:oemcommunity.microsoft.com, DNS:real-stories.microsoft.com, DNS:www.formspro.microsoft.com, DNS:futuredecoded.microsoft.com, DNS:powerautomate.microsoft.com, DNS:smallbusiness.microsoft.com, DNS:upgradecenter.microsoft.com, DNS:learnanalytics.microsoft.com, DNS:onlinelearning.microsoft.com, DNS:businesscentral.microsoft.com, DNS:cloud-immersion.microsoft.com, DNS:analyticspartner.microsoft.com, DNS:businessplatform.microsoft.com, DNS:explore-security.microsoft.com, DNS:kleinunternehmen.microsoft.com, DNS:partnercommunity.microsoft.com, DNS:explore-marketing.microsoft.com, DNS:innovationcontest.microsoft.com, DNS:partnerincentives.microsoft.com, DNS:phoenixcataloguat.microsoft.com, DNS:szkolyprzyszlosci.microsoft.com, DNS:www.powerautomate.microsoft.com, DNS:successionplanning.microsoft.com, DNS:lumiaconversationsuk.microsoft.com, DNS:successionplanninguat.microsoft.com, DNS:businessmobilitycenter.microsoft.com, DNS:skypeandteams.fasttrack.microsoft.com, DNS:www.microsoftdlapartnerow.microsoft.com, DNS:commercialappcertification.microsoft.com, DNS:www.skypeandteams.fasttrack.microsoft.com
X509v3 CRL Distribution Points:
Full Name:
URI:http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft%20IT%20TLS%20CA%204.crl
URI:http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20IT%20TLS%20CA%204.crl
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.311.42.1
CPS: http://www.microsoft.com/pki/mscorp/cps
X509v3 Authority Key Identifier:
keyid:7A:7B:8C:C1:CF:E7:A0:CA:1C:D4:6B:FA:FB:E1:33:C3:0F:1A:A2:9D
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
Signature Algorithm: sha256WithRSAEncryption
1f:d8:61:7a:61:9e:d0:15:f9:4b:72:e4:33:e9:13:0c:7b:75:
c4:5b:06:19:97:dd:f7:d3:c9:2f:15:2c:ee:83:46:bd:8a:d0:
8a:6c:bc:5e:74:d2:53:80:58:17:ea:fd:d8:83:01:0e:d8:24:
b5:ee:34:de:5d:bb:d2:16:65:af:fd:59:89:38:c1:af:c0:cf:
e7:31:76:fb:22:b9:6f:f7:b6:91:54:2d:c9:da:81:cb:8f:84:
b4:0c:8b:c6:f4:5e:6c:65:a3:ec:c3:be:02:29:8f:67:d3:ef:
84:58:8f:18:75:0a:bb:97:63:1e:51:b2:1a:35:11:12:61:45:
26:29:69:08:19:d3:b8:07:96:f0:ff:00:19:40:5e:80:30:83:
c1:91:81:bb:64:f7:16:df:9f:fc:82:a2:3d:2e:f2:f9:46:60:
e4:95:ef:41:2b:69:b6:f6:7f:8d:69:bf:82:72:01:d5:d9:34:
8e:f4:70:67:92:8b:ea:34:b5:cb:b1:b4:71:d4:05:05:a8:d4:
b6:56:c4:0e:5e:94:05:ce:48:72:54:52:d7:67:03:dd:fc:5b:
1d:5d:27:09:65:f1:d3:ee:8c:36:84:35:28:89:26:88:ae:35:
6e:ee:96:64:51:b6:09:0c:d7:5d:d9:60:e2:fb:31:5d:d5:8f:
e6:2e:0c:0b:00:f5:24:27:48:b3:1e:8b:ee:f3:73:8e:82:a9:
89:98:7a:ed:10:1d:52:ce:e5:b4:8a:d8:d8:d0:3a:b0:a7:0e:
da:15:7b:67:f2:3b:35:12:96:ad:87:74:29:d1:b4:db:e6:87:
37:6f:1d:6a:dc:02:aa:45:dd:15:e4:4a:9b:75:f3:22:4c:48:
25:a1:90:1e:55:b7:df:35:8f:67:2f:73:94:69:f0:65:b9:ff:
e8:12:83:ed:98:54:cb:a8:8e:06:7a:2a:45:09:ad:04:77:5b:
3a:bf:ed:24:35:38:e6:4a:45:49:04:26:05:4e:eb:35:7d:26:
c1:d5:dd:03:85:e6:a5:79:33:12:b2:53:ca:ab:67:fc:63:c7:
94:5b:27:30:ce:a5:05:61:f7:62:65:26:a0:d8:9e:3c:dd:35:
4d:51:0c:ab:ae:39:cb:94:b8:58:20:a0:ba:31:5f:e3:b7:d8:
b0:15:15:ec:ee:78:8a:e9:a8:62:ca:02:38:df:6e:dd:34:22:
7f:4f:96:f9:96:10:e7:5e:12:45:df:ed:6d:36:e8:a4:c1:af:
63:3c:ac:3b:f0:aa:bf:44:a5:d7:5c:02:c0:ce:56:58:c5:77:
f5:58:45:9a:64:3d:b2:a7:5f:97:d5:25:d2:e8:40:86:4b:bf:
1c:09:6a:d2:04:d7:d2:a4
Notice Subject: CN=microsoft.com . The subject name contains only the CommonName attribute, not the Organization attribute. And as with essentially all modern website (HTTPS) certs, and many other SSL/TLS certs also, the Subject field is a legacy value that isn't actually used to identify the subject(s) of the cert; the SubjectAlternativeName extension is used instead.
OTOH the CA that issued this cert is also part (a different part) of Microsoft:
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=Microsoft IT TLS CA 4
which does have an Organization attribute identifying Microsoft. However this is rare; very few companies run their own CAs. For example, the current certificate on stackoverflow.com is
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:d5:35:ed:f0:9f:bb:da:42:c1:0c:e8:c6:33:d5:39:38:d9
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Jan 23 07:00:28 2020 GMT
Not After : Apr 22 07:00:28 2020 GMT
Subject: CN=*.stackexchange.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9a:32:f8:05:bf:e1:14:7c:7c:39:f4:ce:37:c6:
ab:27:e2:7f:6d:73:68:8a:87:a2:c6:1e:f1:bd:39:
a3:52:86:99:a8:2d:45:91:e3:f6:ee:ea:ed:0b:ce:
6a:a9:30:94:97:83:5e:78:d9:8c:db:1a:e2:bc:e0:
ee:b2:b9:f9:b6:80:5a:e3:45:16:b2:fb:42:b7:ca:
e9:57:6d:87:fa:4a:44:6b:0b:5c:b4:12:63:17:a9:
13:2e:fd:85:0c:09:dd:43:c7:78:60:c6:d1:c2:b7:
56:61:d4:9e:72:b7:ea:64:5b:68:0f:d1:b4:5e:73:
08:6d:a5:ee:49:4f:e1:e6:d7:83:bd:4e:19:1a:e4:
4c:86:11:30:3a:a5:60:e9:fe:32:40:e1:be:8d:04:
80:28:a0:7a:7f:37:85:84:29:46:d3:93:8c:21:a1:
f6:cf:00:bd:dc:96:df:0c:94:c8:a3:b0:41:6d:1e:
4a:86:c0:51:c3:9a:7a:8c:55:e3:de:86:7d:1f:3d:
fb:0d:1f:83:ef:23:f6:f3:2a:a2:ff:47:87:a9:cd:
8e:d5:f2:3c:84:1b:88:34:86:63:15:a6:5d:c3:5b:
e8:04:65:20:88:d9:70:4d:d2:31:45:04:38:fa:b9:
3d:04:69:70:19:91:ef:65:79:18:a6:63:50:27:df:
87:9b
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:
F0:61:88:B2:8F:1D:EB:1E:FF:68:BC:BD:7A:D0:AF:9C:0C:34:09:18
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:*.askubuntu.com, DNS:*.blogoverflow.com, DNS:*.mathoverflow.net, DNS:*.meta.stackexchange.com, DNS:*.meta.stackoverflow.com, DNS:*.serverfault.com, DNS:*.sstatic.net, DNS:*.stackexchange.com, DNS:*.stackoverflow.com, DNS:*.stackoverflow.email, DNS:*.superuser.com, DNS:askubuntu.com, DNS:blogoverflow.com, DNS:mathoverflow.net, DNS:openid.stackauth.com, DNS:serverfault.com, DNS:sstatic.net, DNS:stackapps.com, DNS:stackauth.com, DNS:stackexchange.com, DNS:stackoverflow.blog, DNS:stackoverflow.com, DNS:stackoverflow.email, DNS:stacksnippets.net, DNS:superuser.com
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
1.3.6.1.4.1.11129.2.4.2:
......v......... N.f.+..% gk..p..IS-...^...o.j.......G0E. Gt...N...O.wDE...~.P.~s..........!.....X....3.uW....z..*.....X......v.^.s..V...6H}.I.2z.........u..qEX...o.j.......G0E. Q...IB...\,.d.q3.T.2.v...z8..0...!.....6....uBJ.......xj....T...Vc.
Signature Algorithm: sha256WithRSAEncryption
17:cd:09:07:27:8f:14:2e:bc:f0:55:3d:f2:6f:dc:76:27:1e:
ed:55:95:66:64:87:a0:b6:6c:dd:71:e1:d2:cb:f6:44:c4:25:
f7:b3:5f:be:69:16:6b:f1:8b:63:b7:9f:07:73:47:9b:da:d5:
be:b1:6b:7b:c2:2a:7e:cc:e0:37:29:0d:c7:39:30:0f:84:2a:
a9:28:3d:93:a7:1d:33:7a:f0:72:73:b7:72:2e:2a:ab:96:65:
65:f5:af:0b:70:55:13:c7:2c:96:59:0a:b2:ef:c1:14:a2:51:
f6:c7:b3:ef:89:db:2c:7d:a7:8b:ac:17:c2:44:8e:b8:0a:12:
27:ff:bb:de:e7:5d:44:24:c0:1f:79:9b:3e:b1:65:a5:58:98:
cc:f5:ab:3d:e8:8a:70:db:1c:90:14:40:c5:1f:51:4b:b4:7a:
3c:2e:4b:c8:5e:2b:5d:86:42:2d:f1:e9:64:2a:53:00:10:88:
fc:7f:41:bd:8b:91:cc:2d:66:b2:af:ea:70:dd:61:cf:a5:c3:
37:3c:56:a5:db:fc:18:e4:ad:af:0d:42:82:cb:22:d6:d6:93:
54:5d:89:0e:03:d9:49:9f:80:ee:ab:f4:41:b1:0a:1f:82:4b:
94:a5:9e:a0:0d:e4:1e:ad:24:ba:1c:91:96:aa:82:df:12:76:
9e:54:04:55
which as you see also has only CommonName in Subject, and the real identities in SAN instead, but is issued by LetsEncrypt (exactly the case #mat referred to), so the Issuer Organization is Let's Encrypt. Do you want to report that stackoverflow and stackexchange etc are part of Let's Encrypt?
In general certificates are not required to be owned by an organization at all, much less a 'registered' one, and if one is, it isn't necessarily required to have that organization name contained in the cert.
ADDED: Okay, as noted in comments accessing microsoft.com with HTTPS (not just TLS) redirects to www.microsoft.com, which both your python and my OpenSSL ignored but browsers of course follow -- and (my) Chrome seriously confuses because it still shows microsoft.com/$path in the address bar. www.microsoft.com is on Akamai so you will get a different server than me and may get a different cert, but the cert I get is:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2d:00:0c:37:15:62:c4:1d:93:94:08:7f:68:00:00:00:0c:37:15
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=Microsoft IT TLS CA 5
Validity
Not Before: Oct 21 22:04:04 2019 GMT
Not After : Oct 21 22:04:04 2021 GMT
Subject: C=US, ST=WA, L=Redmond, O=Microsoft Corporation, OU=Microsoft Corporation, CN=www.microsoft.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d3:10:ad:42:cd:4c:1d:02:b1:0e:6f:fb:c3:3a:
a7:6c:ef:fb:d0:d7:21:90:b4:06:1a:65:83:41:72:
1d:bb:2b:0d:ff:5c:a9:df:b5:dd:cd:56:3e:ed:61:
ee:cc:84:8d:54:f9:b9:27:c6:14:b1:ee:6e:2d:8b:
b3:f3:b7:a9:b1:42:24:d9:fc:a7:a0:62:1c:68:b1:
dd:ec:38:48:a4:5e:02:55:cc:40:af:87:43:2f:77:
a6:9d:ae:f8:b4:d1:c5:1e:43:3d:1d:96:45:24:bb:
13:00:8e:21:6c:f8:55:fb:3a:07:f8:c6:df:2e:6f:
88:4a:64:f1:81:f3:9b:c3:9d:04:34:38:75:61:2f:
d2:2e:51:b6:07:86:68:7c:12:80:c4:75:1f:a8:83:
e9:63:ee:ee:4e:2a:dd:d8:11:69:ed:81:b9:df:57:
57:7a:e9:4e:7d:91:fa:79:0e:0e:13:ff:31:63:ab:
3f:e5:53:72:86:05:68:23:d1:8a:31:1f:c2:86:7e:
ea:b6:61:f1:50:b2:6e:d0:e0:c0:c9:9d:1d:8f:35:
46:f0:c2:b2:b9:26:57:5c:46:7d:bb:a3:94:95:67:
16:81:e7:96:ec:77:21:d6:2f:41:9b:1b:92:68:20:
85:a0:f2:91:89:5c:a6:06:7c:04:43:11:58:d6:8a:
30:4f
Exponent: 65537 (0x10001)
X509v3 extensions:
1.3.6.1.4.1.11129.2.4.2:
...h.f.v..\./.w0".T..0.V..M..3.../ ..N.d....m.bqq.....G0E.!.......L.O.:D.9.F...
.e..$..<..... ..s....'}..o..+....EL.1bN.W.&....u.U.....6.J...W<S...8xp%../..........m.br......F0D. Z&..b.>...r....j-.D.2nH.q{.D.&... E...........D.9.gp.iE(.CO.+B2.~S.u.}>.....Uh$....R.y+..x...j.h.~".....m.bq......F0D. d..z%.t..W.C.}E+.....~...>).1.O.. h....%<..N..9w...VY.......x...fC
1.3.6.1.4.1.311.21.10:
0.0
..+.......0
..+.......
1.3.6.1.4.1.311.21.7:
0/.'+.....7.....u...........a...`.]...B...z..d...
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt
OCSP - URI:http://ocsp.msocsp.com
X509v3 Subject Key Identifier:
F6:AB:BF:05:1E:41:B7:70:E9:91:F8:1A:95:6E:F6:0C:2B:09:FB:95
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Subject Alternative Name:
DNS:wwwqa.microsoft.com, DNS:www.microsoft.com, DNS:staticview.microsoft.com, DNS:i.s-microsoft.com, DNS:microsoft.com, DNS:c.s-microsoft.com, DNS:privacy.microsoft.com
X509v3 CRL Distribution Points:
Full Name:
URI:http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft%20IT%20TLS%20CA%205.crl
URI:http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20IT%20TLS%20CA%205.crl
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.311.42.1
CPS: http://www.microsoft.com/pki/mscorp/cps
X509v3 Authority Key Identifier:
keyid:08:FE:25:9F:74:EA:87:04:C2:BC:BB:8E:A8:38:5F:33:C6:D1:6C:65
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
Signature Algorithm: sha256WithRSAEncryption
75:63:1a:5b:73:4e:3f:96:2b:e3:b4:a8:c3:55:19:34:b3:26:
0e:5c:4d:8f:3f:bc:0d:c1:e2:7e:54:1f:2a:c2:26:3a:fb:3f:
51:f9:54:ac:c1:97:1b:ba:c7:e7:b3:5b:25:9f:67:62:94:93:
1d:6c:52:25:f2:ac:18:f7:37:a6:07:39:47:5b:31:67:10:db:
ea:50:6e:5c:43:7d:36:f8:49:32:63:f0:06:4c:8a:24:00:27:
8d:83:7a:c8:23:59:3f:85:fa:74:13:8e:35:6f:2e:a2:99:27:
17:e0:91:1c:36:5d:4a:23:1a:16:21:38:7d:50:9e:d0:ba:ce:
f7:46:f8:44:e3:ec:45:5f:33:1e:7e:7b:8b:50:75:eb:d9:f5:
72:ab:0b:5e:b3:07:bc:ad:17:9e:ee:eb:c2:bb:ef:77:90:5b:
39:aa:a6:ec:3a:e0:c0:96:14:93:45:1c:88:d1:1f:73:23:76:
74:d4:5c:0b:1a:1f:59:07:55:19:0a:af:6a:0a:ad:8f:20:c2:
9b:f1:09:e8:32:76:91:69:65:18:78:da:b9:cf:08:90:c6:94:
78:27:9d:4d:8a:61:0a:11:1c:91:7a:11:05:98:a4:66:dc:8b:
d2:86:63:eb:b8:8a:86:de:a6:9b:87:d2:4f:ec:74:66:eb:b9:
c1:dc:d4:a0:24:d0:b0:d4:c7:57:41:92:6d:c5:48:45:c8:26:
68:d8:b0:3f:ed:3e:96:b4:68:71:4a:e3:da:1f:fb:d8:84:0d:
f0:f7:bf:f8:2a:c3:79:52:4d:94:a0:3d:81:63:65:fa:dd:45:
fe:bd:c2:29:69:e4:10:dc:8d:50:24:e0:82:20:92:a2:37:58:
f5:19:23:d6:b4:e2:78:fe:8c:48:15:19:05:67:f7:30:1e:57:
22:e6:8b:39:33:b4:ff:08:4c:f3:7d:64:af:13:46:fe:4d:26:
74:2a:43:b5:d2:af:08:a2:1c:01:1a:e4:28:cf:40:dd:3c:6d:
56:93:9d:f1:ff:64:89:f7:06:68:fa:93:41:8a:fc:7f:18:6b:
34:1f:3a:e2:ab:02:1b:5e:e8:f1:97:24:04:a5:bc:15:8e:47:
fe:34:90:01:96:f5:a9:bc:2c:4d:b0:4c:5c:92:2b:d2:50:0f:
c0:7e:cb:20:01:c9:27:2b:25:1b:45:f7:32:9d:00:46:e9:86:
5a:a5:70:88:73:82:68:b5:ce:d6:24:90:5f:4c:16:e3:2a:3e:
94:6c:56:38:db:ce:22:86:9d:d8:d7:9d:fd:fc:4c:eb:be:5f:
11:50:be:af:e0:c8:e8:12:9b:b7:d0:a1:7c:85:e2:5d:e5:0b:
a8:e6:42:df:2a:76:16:8f
which does have Organization (and Org Unit) in the Subject, as you want. This may or may not be true for other websites/companies.

iOS 13 TLS issue

I have installed iOS 13 beta version and run my framework which contains a lot of network requests, but I got this error:
2019-09-19 15:01:33.566811+0200 ---[395:25439] Connection 4: default TLS Trust evaluation failed(-9814)
2019-09-19 15:01:33.567022+0200 ---[395:25439] Connection 4: TLS Trust encountered error 3:-9814
2019-09-19 15:01:33.567110+0200 ---[395:25439] Connection 4: encountered error(3:-9814)
2019-09-19 15:01:33.569824+0200 ---[395:25439] Connection 4: unable to determine interface type without an established connection
2019-09-19 15:01:33.584952+0200 ---[395:25439] Task <D97FD611-0B48-4DCE-99C9-6A971E5E6524>.<4> HTTP load failed, 0/0 bytes (error code: -1202 [3:-9814])
I tried to find out what cause that problem with no success. Can anyone help me?
Apple has defined stricter rules for TLS server certificates, starting from iOS 13 and macOS 10.15.
All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:
TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.
Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:
TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
And the final note:
Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.
I'm going to add some additional information. To check that your certificate is valid you can open it in Keychain Access and check that it contains correct information:
It expires in less than 825 days;
Signature algorithm isn't SHA-1 (SHA-256, probably);
Public key size isn't smaller than 2048 bits;
There's Extended Key Usage extension with "Server Authentication" purpose;
There's Subject Alternative Name extension that contains server's DNS.
Config example for OpenSSL:
[ ca ]
default_ca = CA_default
[ CA_default ]
default_md = sha256
default_days = 825
[ req ]
prompt = no
default_bits = 4096
distinguished_name = req_distinguished_name
x509_extensions = req_ext
[ req_distinguished_name ]
countryName = ...
stateOrProvinceName = ...
localityName = ...
organizationName = ...
commonName = google.com
[ req_ext ]
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = google.com
DNS.2 = www.google.com
To generate new key-certificate pair run this command:
openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -out certificate.crt -days 825 -config config.cnf

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 Certificate Cannot Be Trusted (COMODO)

I am getting the server ready for PCI DSS. There are no other problems but one which I can't solve. PCI scanner (https://www.hackerguardian.com/), says that SSL certificate can't be trusted:
SSL Certificate Cannot Be Trusted 443 / tcp / www
I have removed all other certificates from the chain, leaving only one that was purchased exactly for this server. It was signed by COMODO which is considered as trustworthy. Here is certificate dump:
openssl x509 -in /usr/local/psa/var/certificates/cert-f1nb7M -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e6:3c:e1:95:56:07:3c:f7:4c:5e:b3:bd:06:6d:37:f0
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Extended Validation Secure Server CA
Validity
Not Before: Nov 17 00:00:00 2015 GMT
Not After : Dec 3 23:59:59 2017 GMT
Subject: serialNumber=04045342/1.3.6.1.4.1.311.60.2.1.3=GB/businessCategory=Private Organization, C=GB/postalCode=BN27 2BY,
ST=East Sussex, L=Hailsham/street=Station Road/street=Unit 10 Swan Business Centre, O=Fuss 3 Solutions Ltd,
OU=COMODO EV SSL, CN=www.fuss3inkandtoner.co.uk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...................
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:39:DA:FF:CA:28:14:8A:A8:74:13:08:B9:E4:0E:A9:D2:FA:7E:9D:69
X509v3 Subject Key Identifier:
D1:C0:72:40:F1:A4:47:A6:FF:32:C4:56:6F:EF:F5:1E:40:6A:72:DC
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.5.1
CPS: https://secure.comodo.com/CPS
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/COMODORSAExtendedValidationSecureServerCA.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/COMODORSAExtendedValidationSecureServerCA.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:www.fuss3inkandtoner.co.uk, DNS:fuss3inkandtoner.co.uk
1.3.6.1.4.1.11129.2.4.2:
............
Signature Algorithm: sha256WithRSAEncryption
...............
Certificate is real, it is not expired and domain matches. I have tried other online diagnostic tools like https://www.ssllabs.com/ssltest/analyze.html?d=fuss3inkandtoner.co.uk and everyone says that certificate is good. Everyone but hackersguardian.com which I need to pass for PCI Compliance.
I am not a sysadmin and this certificate was installed by someone else (I think hosting support's sysadmin). I need your advise on how to solve this problem. Thank you in advance.
It was a false positive. Its a very strange thing when security scanner from COMODO (hackerguardian.com) reports a bad certificate issued by COMODO (!).
This tool will clarify the issue you have: https://decoder.link/sslchecker/?hostname=www.hackerguardian.com&port=443
CA bundle installed along with the certificate is malformed (incorrect order). The certificate itself is good and valid, however its validity cannot be verified against the CA bundle, thus it is expected.
here is the correct one bundle: http://helpdesk.ssls.com/hc/en-us/article_attachments/201576002/COMODO_OV_SHA-256_bundle.crt
You can pass that to your hosting so they can reinstall that for you. After that,all will be ok. trust me :)