One of our Jenkins builds is failing trying to connect to build.shibboleth.net. So I did some analysis.
Please look at these openssl results from 2 regions.
In South Asia region: It gives the cert of test.shibboleth.net, which is wrong.
$ openssl s_client -host build.shibboleth.net -port 443 -prexit -showcerts
CONNECTED(00000005)
depth=1 C = US, ST = Ohio, O = Shibboleth Consortium, CN = Shibboleth Project Intermediate CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=Ohio/O=Shibboleth Consortium/CN=test.shibboleth.net
i:/C=US/ST=Ohio/O=Shibboleth Consortium/CN=Shibboleth Project Intermediate CA
...
...
In USA region: It gives the cert of shibboleth.net, which is correct.
$ openssl s_client -host build.shibboleth.net -port 443 -prexit -showcerts
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = shibboleth.net
verify return:1
---
Certificate chain
0 s:CN = shibboleth.net
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
...
...
And resolveip build.shibboleth.net gives 3.213.250.186 from both regions.
Why is it giving a wrong certificate for one region? I have no clue how to fix this. Any ideas?
I'd speculate that the results above aren't caused by region dependence but instead that you're using a different version of openssl on the two client machines.
We used to run the different vhosts on different IP addresses. Now, one address is used for everything and we rely on SNI to distinguish requests so that the right certificate is returned.
If the openssl client doesn't present the server name then you might get a default certificate instead of the one you expected. Whether openssl does that or not depends on the version of openssl in use (openssl version 1.1.1 does, earlier versions don't).
You can try adding -servername build.shibboleth.net to your openssl command to see if that changes the behaviour.
Related
I am using the command ...
openssl s_client -showcerts -connect reds-cluster-01:443
And I get the output:
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
verify return:1
depth=0 CN = *.my-co-example.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=*.my-co-example.com
i:/C=US/O=DigiCert Inc/CN=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
-----BEGIN CERTIFICATE-----
MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ
...
I assume that means somewhere on the filesystem of my server there would be a file somewhere that has the string ...
MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ
... in it. How can I find that file without having to execute something like?
sudo grep -sr MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ /
I assume that means somewhere on the filesystem of my server there would be a file somewhere that has the string ...
This assumption is wrong. What you see is part of the server certificate, which need to be checked against a CA certificate located in the local trust store. The server certificate is typically not in the local trust store. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more on certificates are checked.
You can see more with "CURL -W CERTS" from Daniel Stenberg (also on Stack Overflow), which works on curl for the past 25+ years.
When a client connects to a TLS server it gets sent one or more certificates during the handshake.
Those certificates are verified by the client, to make sure that the server is indeed the right one: the server the client expects it to be; no impostor and no man in the middle etc.
When such a server certificate is signed by a Certificate Authority (CA), that CA’s certificate is normally not sent by the server but the client is expected to have it already in its CA store.
(So no file to check on the filesystem)
Ever since the day SSL and TLS first showed up in the 1990s user have occasionally wanted to be able to save the certificates provided by the server in a TLS handshake.
The openssl tool has offered this ability since along time and is actually one of my higher ranked stackoverflow answers.
Now (for curl 7.88.0,to be shipped in February 2023), Daniel proposes:
Using the –write-out (-w) option and the new variables %{certs} and %{num_certs}, curl can now do what you want.
Get the certificates from a server in PEM format:
$ curl https://curl.se -w "%{certs}" -o /dev/null > cacert.pem
$ curl --cacert cacert.pem https://curl.se/
That is easier to parse than the openssl s_client -showcerts -connect current alternative.
I have created a CloudFront distribution to front some publicly accessible content from an S3 origin. This is all fine, but I need to set the minimum supported TLS version to 1.2.
It seems that the only way to do this is to import a custom SSL certificate and set the ViewerCertificate properties, specifically the MinimumProtocolVersion. I can have Certificate Manager issue a public cert but I don't want to have to register a domain. For the purpose of this content, I'm happy with the default cloudfront.net domain.
It seems like specifying the minimum TLS version should be supported by default. Am I missing something here?
Thanks,
John
This might not be supported forever, but it turns out you can import a bogus, self-signed certificate for the default domain. CloudFront will ignore it, but will enforce your TLS policy.
For example, I'm currently testing this on d2uwa7ugi8xf89.cloudfront.net -- configured with security policy TLSv1.2_2019. openssl s_client will show that it's vending the default certificate:
% openssl s_client -servername d2uwa7ugi8xf89.cloudfront.net -tls1_2 -connect d2uwa7ugi8xf89.cloudfront.net:443
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global CA G2
depth=0 C = US, ST = Washington, L = Seattle, O = "Amazon.com, Inc.", CN = *.cloudfront.net
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=*.cloudfront.net
i:/C=US/O=DigiCert Inc/CN=DigiCert Global CA G2
1 s:/C=US/O=DigiCert Inc/CN=DigiCert Global CA G2
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
---
...
Attempt to connect with TLS 1.0 or TLS 1.1? No go:
% openssl s_client -servername d2uwa7ugi8xf89.cloudfront.net -tls1_1 -connect d2uwa7ugi8xf89.cloudfront.net:443
CONNECTED(00000003)
139725480863648:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:s3_pkt.c:1493:SSL alert number 70
139725480863648:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
...
This certificate was generated in the usual bogus self-signed certificate way:
openssl genrsa 2048 > cf.privkey
openssl req -new -subj /CN=d2uwa7ugi8xf89.cloudfront.net -key cf.privkey -out cf.csr
openssl x509 -in cf.csr -req -signkey cf.privkey -out cf.pem -days 99999
I'm working on a twisted server where there should be a two way SSL handshake. I'm very new to working with these tools so I'm not sure how to set this option. This is my reactor:
def main(reactor):
with open('/opt/ssl/cert.pem') as f:
certdata = f.read()
with open('/opt/ssl/issuer.pem') as f:
issuer_certdata = f.read()
log.info("SSL Certificate Loaded.")
certificate = ssl.PrivateCertificate.loadPEM(certdata)
issuer_certificate = ssl.PrivateCertificate.loadPEM(issuer_certdata)
options = ssl.CertificateOptions(privateKey=certificate.privateKey.original,
certificate=certificate.original,
raiseMinimumTo=ssl.TLSVersion.TLSv1_2,
trustRoot=ssl.trustRootFromCertificates([issuer_certificate]))
factory = protocol.Factory.forProtocol(MPG)
reactor.listenSSL(6060, factory, options)
return defer.Deferred()
From reading https://twistedmatrix.com/documents/16.2.0/api/twisted.internet.ssl.CertificateOptions.html, I found I need to be using the trustRoot argument, and pass it an object that holds the CA. Now, in my case, the server and the clients all have the same CA, so I pass that certificate, such that the CA from that certificate is trusted.
Yet, this doesn't work somehow, and our wireshark tests fail with an error message saying with unknown CA during client certificate valdiation. I don't know if that is because I configured the twisted server wrong, or because the CA info simply doesn't match.
Edit: Since Jean-Paul's original comment, I've tried using the intermediary, the CA and both of them combined as the trustRoot argument, using trustRootFromCertificates. All of them result in an unknown CA error.
PS. I'm on a Centos7, and I've updated /etc/pki/ca-trust/source/anchors/ to include the CA certificate. and ran update-ca-trust
PS2. Testing my server with the command below, I found that it can't validate my own chain when I delete trustRoot from my code above. openssl s_client -connect x.x.x.x:6060 -tls1_2 -state -cert cert.pem -key cert.pem
That is, without the trustRoot argument, this is the certificate chain from openssl:
---
Certificate chain
0 s:C = TR, O = MYCERT
i:C = TR, CN = MYCERT's issuer
---
While, with the trustRoot argument I'm getting:
---
Certificate chain
0 s:C = TR, O = MYCE
i:C = TR, CN = MYCERT's issuer
1 s:C = TR, CN = MYCERT's issuer
i:C = TR, L = ROOT CA
---
I don't know why trustRoot causes this change. I'm probably misunderstanding the whole thing, and am very lost. Any help would be appreciated.
I'm trying to verify whether a TLS client checks for server name indication (SNI).
I'm trying at first to reproduce the steps using openssl.
I tried to connect to google with this openssl command
openssl version
openSSL 1.1.1b 26 Feb 2019
openssl s_client -connect google.com:443 -servername "ibm.com"
Purposely I set the TLS extension -servername to a wrong domain, and I expect that openssl refuses connection, but it proceeds.
I also tried specifiying a CA certificate but nothing happened.
What should I expect when choosing a wrong SNI?
Log
openssl s_client -connect www.google.com:443 -servername "ibm.com"
CONNECTED(000001BC)
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
i:C = US, O = Google Trust Services, CN = GTS CA 1O1
1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFiTCCBHGgAwIBAgIRAOojQokwkAg5AgAAAABSqVUwDQYJKoZIhvcNAQELBQAw
QjELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczET
MBEGA1UEAxMKR1RTIENBIDFPMTAeFw0xOTEyMjAxMzEzNDNaFw0yMDAzMTMxMzEz
NDNaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH
Ew1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgTExDMRcwFQYDVQQDEw53
d3cuZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMdb
zkTc78UBXe8/rti2OxAGZQUQ1WnilkCSqRuMn/gmc1jeiIDeZCWFurFin9+RBB/K
ib5xQx2iZ1ifcV+DOvDT16LEa887TehETAADpBnTJmVi0Z6GXjQQ9pyLrv+1PDYI
3z9Slkw3ZGVeMUE31etonDRB9lPN9skF09s1LvitIi4XdPXgaTNCBEWNMs1Tlv8H
1+UlaQiamriyTii4pptXv+KKsunDC//OEv1pm0cZnEeop8USMHermBzYkaFXC3ae
2hvV7Bj7w8c6PqHcTQ+e7xhoKoIzFVtneNoEyQL1h9QGtPdTofs/sidgd//Wo7sB
0JV1zq2EtSsKlp/N+U0CAwEAAaOCAlIwggJOMA4GA1UdDwEB/wQEAwIFoDATBgNV
HSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQiK5HMzk32
vjkQNky4VkFcyt/kQTAfBgNVHSMEGDAWgBSY0fhuEOvPm+xgnxiQG6DrfQn9KzBk
BggrBgEFBQcBAQRYMFYwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnBraS5nb29n
L2d0czFvMTArBggrBgEFBQcwAoYfaHR0cDovL3BraS5nb29nL2dzcjIvR1RTMU8x
LmNydDAZBgNVHREEEjAQgg53d3cuZ29vZ2xlLmNvbTAhBgNVHSAEGjAYMAgGBmeB
DAECAjAMBgorBgEEAdZ5AgUDMC8GA1UdHwQoMCYwJKAioCCGHmh0dHA6Ly9jcmwu
cGtpLmdvb2cvR1RTMU8xLmNybDCCAQIGCisGAQQB1nkCBAIEgfMEgfAA7gB1ALIe
BcyLos2KIE6HZvkruYolIGdr2vpw57JJUy3vi5BeAAABbyOoMvgAAAQDAEYwRAIg
Ba8Zw9vk29aITM7udOH9zPzytfh5vjTxz2JPuNQuF6gCIEcduOoMHCV9s3G9uEwV
KXwfjtYwYvVlfKlCMW4ilFujAHUAXqdz+d9WwOe1Nkh90EngMnqRmgyEoRIShBh1
loFxRVgAAAFvI6gzIgAABAMARjBEAiBRslW536auv4WHgspy1wNvLEwS2VH66MMV
MJUcgN6IvwIgepYRaAuSuiJeAla6KuAnPCeJvXlscWTnFbm85DIEaegwDQYJKoZI
hvcNAQELBQADggEBAKqExHCpU6rjr/XMezkzy+fp76TST2l39vqIJKDdkQPe8V0I
afWgkc/T3z4bZx/4plzW+iAvk4KTyvDWNbv2xh3njAB6FoJyZkf9/H6zahLSaS4z
qiI3axO3rSD6AW6G5u5cKIN8IaJzLc6CgW+NkxMulOM//u008jZIvp6qGwVfeMlc
1kDocDf8imLam7yM4BQKvOPb5w7e+SgKO6qxRkhFsL18xgh7HZk8F1fvFFhGyuYQ
WL0jORJvjomn/uMxiU9UFlAiVtsY0zmyuVIEp2rDpdfaG8AnVV4BLnR6Ey8TpHzR
w1b3ocoOJi0is55pSMwU8L9RE7cz9MP9krrb7zU=
-----END CERTIFICATE-----
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3018 bytes and written 389 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 20 (unable to get local issuer certificate)
---
The certificate you got back is not yours, it's Google's.
Google implements SNI. Your request states that it wants to establish a connection with the hostname "ibm.com" that Google does not know about. So it decides to answer with its own certificate.
If this was a browser, you would get a name mismatch warning of some kind.
So to answer your question, to test an invalid SNI, look for the hostname in the output. Here is a command I use:
echo -n | openssl s_client -connect google.com:443 -servername ibm.com | openssl x509 -noout -text | grep ibm.com
You won't get any hits, that means that either SNI is not supported or the server you are connecting to does not recognize it.
I am checking on a Mac and I had to make a modification by adding the -connect directive.
echo -n | openssl s_client -connect google.com:443 -servername ibm.com | openssl x509 -noout -text | grep ibm.com
Since we don't need to input anything, I'd update the command to close the openssl command by forcing input from /dev/null:
echo -n | openssl s_client -connect google.com:443 -servername ibm.com </dev/null | openssl x509 -noout -text | grep ibm.com
I am trying to verify a certificate file with OpenSSL. Can you explain me why s_client connection succeeds, but verify file with the same certificate chain fails? How can I verify the file?
Note I compiled OpenSSL 1.0.1k myself, it shouldn't be using any distro-specific config. And I provided the same CAfile to both commands.
$ openssl s_client -CAfile /etc/pki/tls/certs/ca-bundle.crt -connect www.google.com:443
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
...
Verify return code: 0 (ok)
---
If I run it with -showcerts argument, it outputs all three certificates sent from server. I concatenated them into file google.pem. But the chain can't be verified. See:
$ openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt google.pem
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
google.pem: C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
error 20 at 0 depth lookup:unable to get local issuer certificate
Applying a patch suggested on https://stackoverflow.com/a/27606964/1823988 doesn't help.
I found it. openssl verify doesn't expect certificate file to contain its chain. Chain needs to be passed with -untrusted argument. It works with the same file, trust is still determined by finding a trusted root in -CAfile.
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt -untrusted google.pem google.pem