Re: How to rotate cert when only first matching cert been verified

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

定平袁 <pkudingping@xxxxxxxxx> 于2020年12月25日周五 上午7:35写道:
Thanks a lot for your reply! Merry Christmas!

@Michael Wojcik   Apologies. 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 <Jochen.Bern@xxxxxxxxx> 于2020年12月24日周四 下午7:44写道:
On 23.12.20 23:56, openssl-users-request@xxxxxxxxxxx digested:
> Message: 4
> Date: Wed, 23 Dec 2020 23:56:44 +0100
> From: David von Oheimb <dev@xxxxxxxx>
[...]
> 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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux