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 <module>
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 := &http.Client{
Transport: &http.Transport{
TLSClientConfig: &tls.Config{
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 -vvvv -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?
定平袁 <pkudingp...@gmail.com> 于2020年12月25日周五 上午7:35写道：
> Thanks a lot for your reply! Merry Christmas!
>
> @Michael Wojcik <michael.woj...@microfocus.com> Apologies. I clicked
> the wrong reply button.
>
> @David von Oheimb <d...@ddvo.net> 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 <jochen.b...@binect.de> 于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 <d...@ddvo.net>
>> [...]
>> > 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
>>
>>
