libest
libest copied to clipboard
cisco
Certificate of https://testrfc7030.com is expired.
Openssl shows the certificate is expired, which causes any https connection failed. Can you please take a look at it? Thanks. jerry@jerry-linux:~/est$ openssl s_client -connect testrfc7030.com:8443 CONNECTED(00000003) 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 = testrfc7030.com verify error:num=10:certificate has expired notAfter=Dec 13 21:51:36 2018 GMT verify return:1 depth=0 CN = testrfc7030.com notAfter=Dec 13 21:51:36 2018 GMT verify return:1
Thanks. Overnight jenkins job found it and it was updated earlier today. Should be using the renewed cert now.
Thanks again,
The certificate has expired again (expired back in mid-March). Can this please get renewed?
_curl: (60) SSL certificate problem: CA signature digest algorithm too weak More details here: https://curl.haxx.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._
Hey, is this a client-side issue?
Cheers Rob
just noticed that the certificate for testrfc7030.pem expired again.
root@ub18-04:~/est# echo -n | openssl x509 -text -in testrfc7030.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: ecdsa-with-SHA1
Issuer: CN = estExampleCA
Validity
Not Before: Aug 13 16:34:57 2019 GMT
Not After : Aug 12 16:34:57 2020 GMT
Subject: CN = testrfc7030.com
Any chance for a fix?
@grindsa this is fixed now. Try it out. Thank you for bringing it up. We forgot to renew it again.
It does not matter but I am curious. How are you using the testrfc7030 server? As a test, PoC, to get certs for your application in production?
Thank you for fixing. I did test and can confirm that the problem is solved.
One other small remark: I see that the certificate has a CN=testrfc7030.com but is missing an SubjectAltName for testrfc7030.com. This will sooner or later cause issues as RFC2118 mandates the presence of subjectAltNames for identity checking (my python library already complains on it) . Maybe its a good idea to renew the cert again and replace the certificate with one having a proper SAN.
to answer your 2nd question: I am developing an acme-proxy which allows acme clients to connect to various enterprise CAs. I have a generic CA-handler for EST protocol and use testrfc7030.com to test certificate enrolments as part of release regression.
Thanks for the details @grindsa . Understood.
One other small remark: I see that the certificate has a
CN=testrfc7030.combut is missing an SubjectAltName fortestrfc7030.com. This will sooner or later cause issues as RFC2118 mandates the presence of subjectAltNames for identity checking (my python library already complains on it) . Maybe its a good idea to renew the cert again and replace the certificate with one having a proper SAN.
We could change the CA config to include a SAN, but from RFC2818
[...] Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
So, it is not a mandatory thing. It is encouraged in the RFC, but it is normative language (MUST, MUST NOT, SHOULD, SHOULD NOT etc). urllib might still complain, but they should not hard fail on it.
The above statement rather refers to CN tan to SAN. I read it in a way that you have to have a SAN but there is no need to set an CN. This btw would be inline with the behavior of urllib.
BTW: if you are replacing the certificate an you please also sign it with ecdsa-with-sha256 instead of ecdsa-with-sha1. This will stop clients complaining about weak signature digest algorithm.
curl https://testrfc7030.com:8443/.well-known/est/cacerts -o /tmp/cacerts.p7 --cacert /tmp/dstcax3.pem
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: CA signature digest algorithm too weak
More details here: https://curl.haxx.se/docs/sslcerts.html
Oh yes please. Think that was the problem I had. Rob
Many thanks Rob
From: grindsa [email protected] Sent: Thursday, August 20, 2020 3:49:47 PM To: cisco/libest [email protected] Cc: Milchem, Rob [email protected]; Comment [email protected] Subject: Re: [cisco/libest] Certificate of https://testrfc7030.com is expired. (#67)
Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
BTW: if you are replacing the certificate an you please also sign it with ecdsa-with-sha256 instead of ecdsa-with-sha1. This will stop clients complaining about weak signature digest algorithm.
curl https://testrfc7030.com:8443/.well-known/est/cacerts -o /tmp/cacerts.p7 --cacert /tmp/dstcax3.pem % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: CA signature digest algorithm too weak More details here: https://curl.haxx.se/docs/sslcerts.html
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcisco%2Flibest%2Fissues%2F67%23issuecomment-677712481&data=02%7C01%7Crobert.milchem%40atos.net%7Cace32ad235e540a6c16c08d845185dac%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637335318236260347&sdata=ahXiYQQNJMkwbH836mBvjCV7guQgb8MnkcelnJ33NnY%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQIXZSS26KHYCYOMX5CLUJTSBUZYXANCNFSM4GKP6SJQ&data=02%7C01%7Crobert.milchem%40atos.net%7Cace32ad235e540a6c16c08d845185dac%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637335318236260347&sdata=tnYqBIJj3hMyhYSOUQINc2s8qM%2FUJHWHXq5boX3eh7E%3D&reserved=0.
BTW: if you are replacing the certificate an you please also sign it with ecdsa-with-sha256 instead of ecdsa-with-sha1. This will stop clients complaining about weak signature digest algorithm.
curl https://testrfc7030.com:8443/.well-known/est/cacerts -o /tmp/cacerts.p7 --cacert /tmp/dstcax3.pem % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: CA signature digest algorithm too weak More details here: https://curl.haxx.se/docs/sslcerts.html
This is addressed now. The new testrfc7030 cert has a SAN and also uses ecdsa-with-sha256.
It will also issue certs with sha256 as the message digest now instead of sha1.
Closing this git issue now.