Re: How to rotate cert when only first matching cert been verified
定平袁 you are welcome. The OpenSSL version you are using is way too old! Do not use version 1.1.0, 1.0.x, and anything older - those versions are unsupported and must be considered insecure. 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. I've just clarified this and some further details in https://github.com/openssl/openssl/pull/13735. I think Michael Wojcik already gave the right hint to solve your problem two days before: > Why are you appending it to the file containing the existing certificate? So I suggest you better prepend the new certificate to that file rather than appending it, or even better, remove the old (non-matching) certificate from that file. Hope this helps, David P.S.: I will be unavailable for several days, too. On 23.12.20 04:15, 定平袁 wrote: > @David Thanks for you help! > This is my openssl version, and the self compiled curl backend > ``` > $ openssl version > OpenSSL 1.0.2g 1 Mar 2016 > > $ ldd /usr/bin/openssl |grep ssl > libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x7f3099799000) > > $ ldd ./lib/.libs/libcurl.so |grep ssl > libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x7f8720fd4000) > ``` > the system built-in curl binary: > ``` > $ ldd /usr/bin/curl |grep tls > libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 > (0x7f4b7fa07000) > libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 > (0x7f4b7e851000) > ``` > Actually, the old cert and new cert both are not expired yet, just the > old cert is not consistent with server side. The new cert has the same > content with server side imported cert(after replaced). > > David von Oheimb mailto:d...@ddvo.net>> 于2020年12月22日周二 > 下午10:27写道： > > @定平袁, which version of OpenSSL are you using? > > I've just checked: since OpenSSL 1.1.0, expired certificates are > effectively not used for chain building. > > David > > On 20.12.20 02:02, 定平袁 wrote: >> the exact behavior: >> >> When looking up CA certificates, the OpenSSL library will first >> search the certificates in *CAfile*, then those in *CApath*. >> Certificate matching is done based on the subject name, the key >> identifier (if present), and the serial number as taken from the >> certificate to be verified. If these data do not match, the next >> certificate will be tried. If a first certificate matching the >> parameters is found, the verification process will be performed; >> no other certificates for the same parameters will be searched in >> case of failure. >> >> why no other certificates for the same parameters will be searched? >> >> 定平袁 mailto:pkudingp...@gmail.com>> >> 于2020年12月20日周日 上午8:59写道： >> >> Hello everyone, >> >> Recently I am trying to rotate a cert, and the client uses >> python requests lib, which leverages openssl. Here is my steps: >> >> 1. Generate a new cert, and append it to the cert file(at >> this point, there are 2 certs in the file, first is old cert, >> second is new, they have the same Subject), restart client >> side process, (no problem here, because first cert matching >> server side cert, and it verifies successfully) >> 2. Replace server side with new cert. >> >> As soon as I issue step #2, the client side process starts to >> show error “certificate verify failed”. This would cause >> downtime to my apps. I am new to this, not sure if there is >> anything wrong regarding my usage or understanding. But I >> found this page >> >> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html, >> it says the exact behavior like my test: >> >> If several CA certificates matching the name, key identifier, >> and serial number condition are available, only the first one >> will be examined. This may lead to unexpected results if the >> same CA certificate is available with different expiration >> dates. If a "certificate expired" verification error occurs, >> no other certificate will be searched. Make sure to not have >> expired certificates mixed with valid ones. >> >> So I am wondering how to rotate cert in such a case? It would >> be very helpful if anyone could help on this. Thanks. >> >> BTW, I tested the same cert file with CURL (compiled with >> gnutls), it works fine. >> >> Regards >> Dingping >>
RE: How to rotate cert when only first matching cert been verified
> From: 定平袁 > Sent: Tuesday, 22 December, 2020 20:08 > To: Michael Wojcik Please do not send messages regarding OpenSSL to me directly. Send them to the openss-users list. That is where the discussion belongs. > > Why are you appending it to the file containing the existing certificate? > I am rotating certificate, before the server side cert been replaced, the > client > side cert need to be valid, so when rotating, need both old and new cert > exist. I'm afraid it still isn't clear to me what you're doing. Both the server's entity certificate and the client's entity certificate are in the same file? What does this file contain before you append the new certificate? > > It sounds like you're updating the server's entity certificate. > I guess it's entity certificate (still trying to understand different cert > concept...) Does it identify the server, in the Subject DN and/or one or more Subject Alternative Name extensions? > Below is the error message: I'm afraid that message doesn't appear to contain any useful information. > All the 3 clients used the same ca.crt file, which has an old cert in > first, then a new cert behind. Only Python (used OpenSSL) failed. So *this* sounds like what you're changing in this particular file is the set of trust anchors, not the entity certificates. Where did your "CA" certificates come from? A commercial CA or some personal or organizational CA? From your description it sounds like the problem may be that the CA certificates were not generated correctly. Without the certificates to examine, we can't say. Can you post the old and new certificates in PEM form in your next message? Please note that due to the holidays I will not be reading email for several days, and it's likely that some other regular list members will be similarly unavailable. -- Michael Wojcik
Re: private key not available for client_cert_cb
Hi,
On 20/12/20 09:39, George wrote:
Hi,
I tried running the "s_client" command and it appears to be working.
I guess there must be something wrong in my code.
it is good news that the s_client command is working - it means there is
something wrong with your code but you have everything at hand to fix
it: download the openssl 1.0.2 tarball / zip file and look for the files
apps/s_client.c
apps/apps.c
that contains all of the code that the 's_client' command uses to make a
connection and my bet is that is also does not call ENGINE_init
My crash occurs when I call
ENGINE_init(pkey_engine);
I notice your code does not call this function. Is this needed
needed? If so, when/where should it be called?
tbh, I don't know - look through the openssl sources to see what it
does, exactly.
What exactly is the definition of "pkey_identifier" in
ENGINE_load_private_key(pkey_engine, *pkey_identifier*,
transfer_pin, _data) ?
I'm not clear on what this value should be. Can you give an example of
what it would look like?
I have the following on my smart card:
Private Key Object; RSA
label: Authentication - *
*ID:**2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba*
Usage: unwrap
Access: sensitive, never extractable
Allowed mechanisms: RSA-PKCS,RSA-X-509
Would the *pkey_identifier* be the *ID* in the above?
yes, although if you have multiple smartcards inserted at the same time
then it helps to add the slot number, e.g.
0:
What exactly is "prompt_info" in the structure PW_CB_DATA?
i.e.
typedef struct pw_cb_data {
const void* password;
const char* *prompt_info;*
} PW_CB_DATA;
Can you give an example of what it might look like?
Is the value of cb_data populated by the transfer_pin callback
functions, or should it already contain a value when
ENGINE_load_private_key is called?
Is there a way to skip the callback transfer_pin and use a hard coded
pin for test purposes when calling ENGINE_load_private_key(...)?
my eap-tls code does just that: if the password is specified in the ppp
config file then the user is not prompted:
if (pkey_engine)
{
EVP_PKEY *pkey = NULL;
PW_CB_DATA cb_data;
UI_METHOD* transfer_pin = NULL;
cb_data.password = passwd;
cb_data.prompt_info = pkey_identifier;
HTH,
JJK
On 2020-12-19 8:05 p.m., Jan Just Keijser wrote:
I'd say no engine/pkcs11 module should trigger exceptions - that's an
error in the pkcs11 module.
Something you can try is this:
run the 'openssl.exe' command:
openssl engine -t dynamic -pre
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll"
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre "MODULE_PATH:C:\Program
Files (x86)\HID Global\ActivClient\\acpkcs211.dll"
then on the OpenSSL prompt , try
s_client -keyform engine -key 0: -cert "clientcert.pem"
-connect remote_host:remote_port
that should start a TLS connection and use the pcks11 engine to ask
for the key , identified by in slot 0 (adjust the slot
number if your smart card starts at number 1 etc.
HTH,
JJK
Re: Format error in certificate´s notAfter field
On 22/12/2020 17:43, Raúl Uría Elices wrote: > Hi, > > I´m trying to connect to my vpn server, using tunnelblick, but thinking > this is a openssl stuff... may be I am wrong. > > > When connecting I got (XX is a placeholder) : > > 2020-12-22 17:32:49.423703 VERIFY ERROR: depth=0, error=format error in > certificate's notAfter field: C=es, L=P, O=XX, CN=XX, > emailAddress=XX, serial=17702460327850242852 > > I have checked this: > https://mta.openssl.org/pipermail/openssl-users/2019-March/010018.html , > but seems to be something different. > > When checking UTC field for server CA cert, I got: > > % openssl asn1parse -in ca.crt | grep UTC > 207:d=3 hl=2 l= 13 prim: UTCTIME :170908154452Z > 222:d=3 hl=2 l= 13 prim: UTCTIME :360718151218Z I don't see anything obviously wrong with those encodings. Are you willing to share the actual certificate? Matt
