Re: How to rotate cert when only first matching cert been verified
Re post my code here, since I send it alone to Michael. Below is the error message: ``` Traceback (most recent call last): File "test.py", line 6, in r = s.get(' https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag', verify='./ca.pem') File "/home/kubo/.local/lib/python2.7/site-packages/requests/sessions.py", line 555, in get return self.request('GET', url, **kwargs) File "/home/kubo/.local/lib/python2.7/site-packages/requests/sessions.py", line 542, in request resp = self.send(prep, **send_kwargs) File "/home/kubo/.local/lib/python2.7/site-packages/requests/sessions.py", line 655, in send r = adapter.send(request, **kwargs) File "/home/kubo/.local/lib/python2.7/site-packages/requests/adapters.py", line 517, in send raise SSLError(e, request=request) requests.exceptions.SSLError: HTTPSConnectionPool(host='nsxmanager.pks.vmware.local', port=443): Max retries exceeded with url: /api/v1/spec/vmware/types/Tag (Caused by SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)'),)) ``` but the CURL command and Golang code I used to access client, it shows CA cert. My python code(which report above error): ``` import requests s = requests.Session() s.auth = ('admin', 'Admin!23Admin') r = s.get('https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag', verify='./ca.crt') print(r.status_code) ``` CURL: ``` curl -I -u admin:'Admin!23Admin' https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag --cacert ./ca.crt ``` Golang: ``` package main import ( "crypto/tls" "io/ioutil" "log" "fmt" "net/http" "crypto/x509" ) func main() { caCert, err := ioutil.ReadFile("./ca.crt") if err != nil { log.Fatal(err) } caCertPool := x509.NewCertPool() caCertPool.AppendCertsFromPEM(caCert) client := { Transport: { TLSClientConfig: { RootCAs: caCertPool, }, }, } req, err := http.NewRequest("GET", " https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag;, nil) req.SetBasicAuth("admin", "Admin!23Admin") r, err := client.Do(req) if err != nil { panic(err) } fmt.Println(r.Status) } ``` All the 3 clients used the same ca.crt file, which has an old cert in the first, then a new cert behind. Only Python (used OpenSSL) failed. After I compile curl with openssl backend, the new binary failed too. ``` ./curl.openssl - -u admin:'Admin!23Admin' https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag --cacert ./ca.crt * Trying 192.168.111.4:443... * Connected to nsxmanager.pks.vmware.local (192.168.111.4) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: ./ca.crt * CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: self signed certificate * Closing connection 0 curl: (60) SSL certificate problem: self signed certificate More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. ``` Is above information enough? 定平袁 于2020年12月25日周五 上午7:35写道: > Thanks a lot for your reply! Merry Christmas! > > @Michael WojcikApologies. I clicked > the wrong reply button. > > @David von Oheimb I will update to a new version and try > again. To append cert is to make sure new cert and old cert both exist in > trust store, thus when server switches cert, it can be trusted by client. > > @Jochen actually, the certs have different SN, which indeed is not > consistent with the man doc. The thing that confuses me is that CURL > (compiled with gnutls) and Golang works. > below is my ca.crt file, I am not sure where it went wrong, maybe just my > wrong behavior? > > ``` > > -BEGIN CERTIFICATE- > MIIFdzCCA1+gAwIBAgIJAJcvKUQ0Bz4tMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNV > BAYTAlVTMQswCQYDVQQIDAJDQTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8wDQYDVQQK > DAZWTXdhcmUxJDAiBgNVBAMMG25zeG1hbmFnZXIucGtzLnZtd2FyZS5sb2NhbDAe > Fw0yMDEyMTcwMDM2MjBaFw0zMDEyMTUwMDM2MjBaMGUxCzAJBgNVBAYTAlVTMQsw > CQYDVQQIDAJDQTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8wDQYDVQQKDAZWTXdhcmUx > JDAiBgNVBAMMG25zeG1hbmFnZXIucGtzLnZtd2FyZS5sb2NhbDCCAiIwDQYJKoZI > hvcNAQEBBQADggIPADCCAgoCggIBAMC4EFsukdnrj26EYSaCCrvUtEhbi33wXHKi > 6utmOe9r+M17Q0MArjJeEzklmrTkj+qKJCB4TgWFY2djJ+hA0a5I2eOn/0OjJ0c2 > 67FcqX7pq1JwYMSkwN4dQUbAN82xjQOcmj03PVjgLQSFXLfNxcfym0G2KtwkIg8K > V4JwC0L048BBu/EynAXA2kYHXiJ6uSjeMOuTyogmVilzUOjfJztaNj2jpq3D8sek > qtRNBYRcgSwx1wq7uWSe6qjHVDmom4nlUQznOZfJYodFWZll6Wv8Itk28ovhIhgk
Re: How to rotate cert when only first matching cert been verified
Thanks a lot for your reply! Merry Christmas! @Michael WojcikApologies. I clicked the wrong reply button. @David von Oheimb I will update to a new version and try again. To append cert is to make sure new cert and old cert both exist in trust store, thus when server switches cert, it can be trusted by client. @Jochen actually, the certs have different SN, which indeed is not consistent with the man doc. The thing that confuses me is that CURL (compiled with gnutls) and Golang works. below is my ca.crt file, I am not sure where it went wrong, maybe just my wrong behavior? ``` -BEGIN CERTIFICATE- MIIFdzCCA1+gAwIBAgIJAJcvKUQ0Bz4tMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJDQTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8wDQYDVQQK DAZWTXdhcmUxJDAiBgNVBAMMG25zeG1hbmFnZXIucGtzLnZtd2FyZS5sb2NhbDAe Fw0yMDEyMTcwMDM2MjBaFw0zMDEyMTUwMDM2MjBaMGUxCzAJBgNVBAYTAlVTMQsw CQYDVQQIDAJDQTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8wDQYDVQQKDAZWTXdhcmUx JDAiBgNVBAMMG25zeG1hbmFnZXIucGtzLnZtd2FyZS5sb2NhbDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAMC4EFsukdnrj26EYSaCCrvUtEhbi33wXHKi 6utmOe9r+M17Q0MArjJeEzklmrTkj+qKJCB4TgWFY2djJ+hA0a5I2eOn/0OjJ0c2 67FcqX7pq1JwYMSkwN4dQUbAN82xjQOcmj03PVjgLQSFXLfNxcfym0G2KtwkIg8K V4JwC0L048BBu/EynAXA2kYHXiJ6uSjeMOuTyogmVilzUOjfJztaNj2jpq3D8sek qtRNBYRcgSwx1wq7uWSe6qjHVDmom4nlUQznOZfJYodFWZll6Wv8Itk28ovhIhgk G9wJv3QJp6Gef1GN22Q7KU09/ZG61PRPVgoPTuRxHKn75aKl6FJcztvz/X4egt9K yGxsxEtWrLW52U1EUVg0zVUO/VAbtm1NLsEGv1L19vYjg6gpU4zQjP7enuSFqvKo rLLDvSzUWRzXIDwWSWGNBoAkry8jZmKWnjHqSW2EVbCaFTXcIQ6kPQGYvH3cFUyG fW06NlCL+AYGNaOVJkL7J3RYH+5cstGTpCNpyAmYNsEs1G+yXwCH5aDcP/0qbU2W WXO0Jh/+2KhmZ1Op1o6x69FLQ+g/0m705nGhx8NQWC3V+BC/mUdyXlom7yZde+uT qZS/0K7z/O8FpNwAddLmhgNHq2cHRjQFH6WeAhw3tBLGS5OFAP23SG/OItEaWp7h nXgRedMVAgMBAAGjKjAoMCYGA1UdEQQfMB2CG25zeG1hbmFnZXIucGtzLnZtd2Fy ZS5sb2NhbDANBgkqhkiG9w0BAQsFAAOCAgEAlfMDgcI6DiRH7eRJfg0SrtkRSAIe 0icQ8RH6Z8SBYIbPnzR2qeAm0V7BV7qGSOHGb1ezghCXQAjL2JF1pHw9aKZ0ST49 vZSlkp6tKojk1HZqa3OSfji+o8ROSvpfBW+qYqgsTkSD0VqZ4xkGUnXaRbQ3H+2V CV/MsXn/lgJ1pXDhNifUBtTa4OQx3WsA74lh7pddtbEWQJbFPwDvwzKo62P8b6zq MDhccVBmV5QZDwGH3v9Dy6QHq91b1grMkIQb67e1E6VQia6++Sq8b8ZCOJ1VUOjt I7KTIco57dLyIJPO+wvTKKpLraFIGUxNBwVOnI6wekUlhhhMcXvL/dNbD8htO/SQ VtiB8BL8SJ8HlRy2REDwvNMj0ChWeFjimb6k/40vKet3lmmAwewjy4OWBkkfrv3Y /I+RQ8Ua3vsz8KZywZvXAYWTTnsFbsHQBv9TgI0crKajVgm06stz7X+RHmhVyckV 54nSQhzZPagxfwJNzcKNb+HMr57D6SNl8xYLK1V5lmDjtAFeII3fnCJpCszNptKy cHY8Jq1eb5no5cAK7WfvepVQD0CGR6JhEuNpYNa0bp6uGTYv9EqYYqrNq8cx/41v jaNI9N6oqi3Qqt+MARXXLgMjl1CYZQ7mNT0pOXPC6gEFoyKhTnDmACAV82WB1ClR ZlY/eRzAK/iXECs= -END CERTIFICATE- -BEGIN CERTIFICATE- MIIFdzCCA1+gAwIBAgIJAITnARyY8iCRMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJDQTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8wDQYDVQQK DAZWTXdhcmUxJDAiBgNVBAMMG25zeG1hbmFnZXIucGtzLnZtd2FyZS5sb2NhbDAe Fw0yMDEyMTUwOTIzMjVaFw0zMDEyMTMwOTIzMjVaMGUxCzAJBgNVBAYTAlVTMQsw CQYDVQQIDAJDQTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8wDQYDVQQKDAZWTXdhcmUx JDAiBgNVBAMMG25zeG1hbmFnZXIucGtzLnZtd2FyZS5sb2NhbDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAJ1vvdCHRdGFvleEAGANFv9ttVAa4DdewpKK M+DCyOnRfnsfJWxtTSpzu+nDQg9/wvFs2RQBu+Yh1iF40KVc6aYMDjxb+4uAC2nR /0g8ANGXYE1BoDShJwwTosWrQ6RaPTLw3rK4U6+OW//g7EHUR9LRHNRRdItbyXkT ULQac4x/k8ApwXQvFZ6Vb/L+nNBUBJQapWoi361v7Z2fxzmJwB9D+KfGU4pMKKL7 /VuMvDaZuxzeAnPdkaYrmF8XlnUr5ZoW85xWLVLPPRjDqcNiKcXBhUHWUB3+RzEc 1leLcX9yrtiJjO91hTzsTPvd4Tqi8ojyY+SILJiqJRDNcrVtrW+leVlxOGcLgnT3 gR3EB5zAaT8z+RBMn+SPJSUKslh1P/bAyOaPLg3NQwTpk/gDoShGva01y/7/kBnk nvkz6mTl+UZIWCj5cI7a3+zkR6ptNZDArn2JpFW1ePmnQjz+Bt7y6tueJxnj8Q5M cUbEOhcqfzadpJort0/70STtR0LSvLe0Q+8r1sTDuO9RXjqqdbveyp9w+dUFW1et SF/w+ak3f4nZZCjI0FU68HtzNmmqPdgKJuE197J4XNVyCHQW1h0X2zURyvGOYp5D UHsdQYfm6G0aw3VppiT71t5BeBQi2Z6jyVVqGGBf36rhbp8BsP5FxTQI7apXR/u3 jhTblAvHAgMBAAGjKjAoMCYGA1UdEQQfMB2CG25zeG1hbmFnZXIucGtzLnZtd2Fy ZS5sb2NhbDANBgkqhkiG9w0BAQsFAAOCAgEAlvoh8fFQpAzElmkIVLBr739cscLz ALXnBgAFPhR/leoZjdEdHfq7Pm80dtEaluCrm81MX1wKiCJKgA6oAzAf7vK1seu5 Mx4yu9hwpNE9xXheea5cASzvR355JPjvUdFohChuvnVcPV0yZdVzEOhtmyrYPCHd OYcEA0xyV2sqKZRil39dHRi1VRoALZL8n2UHZa1EN0wTHfRKdmx9QOAxhsxhNSMg kiCMGe9OoYfcU98dlXNclvkIqkVl8RN6W4A8z/7VFB/Aq3NQBfGeTR3l/+dZH+e0 boioZDkpGRVCtfYyjvfPRUeMJXgqUfdMIsQGm0YbtQ0PWhIhjdxiuLUJ4jEqen8G 5ssz0/V4vlJ0wgkhliQcybxRhCWayKr95kuV6yiHKZgpTX9ovOhE+Ew208Y6Poh3 vR7YAWfyI7QxPAhSuLMQFKtRbD2cbAQ/CD+CsFVquiGj8J6DUS+pWPr5JHNz8rzA Ba29dMTPeKmbbW3aHZ4pA2aJNT5lmA6RQ85cR7oNU48HAhwSqpw23NZQb2MF7Qqp cTey+etb2kVR83fp47g2hfgzCBKoTYdqC5G5kVarvO1+BsdKwApz+iElUqKfkRZo NwHJp5KUauGKGrN2WY5yAMUq9iEsVlTBt+rsixtnRlP1yhGhc9DrLsKquOw03myL hDISqFnOh+zVz10= -END CERTIFICATE- ``` Jochen Bern 于2020年12月24日周四 下午7:44写道: > On 23.12.20 23:56, openssl-users-requ...@openssl.org digested: > > Message: 4 > > Date: Wed, 23 Dec 2020 23:56:44 +0100 > > From: David von Oheimb > [...] > > Yet since both your old and new server cert are not expired and have the > > same subject, keyIdentifier, and serial number, > > and you appended the new server cert to your list, it is no surprise > > that the certificate chain building algorithm will pick up the old one. > > For
Re: How to rotate cert when only first matching cert been verified
On 23.12.20 23:56, openssl-users-requ...@openssl.org digested: > Message: 4 > Date: Wed, 23 Dec 2020 23:56:44 +0100 > From: David von Oheimb [...] > Yet since both your old and new server cert are not expired and have the > same subject, keyIdentifier, and serial number, > and you appended the new server cert to your list, it is no surprise > that the certificate chain building algorithm will pick up the old one. > For efficiency reasons, no other (equally applicable) certificates will > be tried. To expand on the "*should* you actually do it like this" angle: I do not see any reason why the new server cert (SC) should have *the same serial number* (SN) as the old one. At least in the general case - where the CA and the server are run by different entities -, the CA wants(*) to be able to revoke old and new SC separately, and CRLs identify revoked certs exclusively by the issuing CA Cert (CC) and the revoked cert's SN. So, what *is* the rationale to reuse the SN? Do you have a "verification" mechanism somewhere that (cannot be updated in a timely manner for the new SC and) would protest a changed SN, but *not* the changed validity period (or, for that matter, fingerprint or CA signature)? Note that the mere thought already makes me put quote marks around "verification" ... Disclaimer: I'm *not* saying that merely using different SNs will make the problem you're currently experiencing disappear. In fact, I consider that rather unlikely, but it might be one contributing factor. (*) Scenario 1: Before the old SC expires, the CA finds out that it issued a new SC to an imposter, so they now want to revoke the new but not the old. Scenario 2: The old SC is found to have been leaked after the new one was already issued, so at least the server admin would prefer to have the old SC revoked but *not* the new one. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature
BIO_s_file() and files that are larger than int - how is overflow handled?
Hi all, According to the manpage at https://www.openssl.org/docs/man1.1.0/man3/BIO_s_file.html the macro BIO_tell() casts to int: /opt/local/include//openssl/bio.h:# define BIO_tell(b) (int)BIO_ctrl(b,BIO_C_FILE_TELL,0,NULL) What happens if the file being parsed is larger than can fit in an int? Does BIO_s_file() do anything to limit the size of the file? Does openssl detect overflow, or do I have to detect overflow? Regards, Graham —