Strange problem: openssl verify not working on Proxmox VM, works on a bare metal system
On an AlmaLinux 8.6 VM hosted in Proxmox: [root@certs ~]# openssl verify -CAfile /etc/ssl/certs/local/DOMAIN.wildcards.pem /etc/ssl/certs/local/DOMAIN.wildcards.pem C = US, O = Let's Encrypt, CN = R3 error 2 at 1 depth lookup: unable to get issuer certificate error /etc/ssl/certs/local/DOMAIN.wildcards.pem: verification failed [root@certs ~]# openssl version OpenSSL 1.1.1k FIPS 25 Mar 2021 The VM has CPUs of type host. It did the same with a CPU type of kvm64. I switched to host because kvm64 did not pass the aes CPU flag through. If I copy the PEM file to a bare metal system running Ubuntu Server 20.04, it verifies: elyograg@bilbo:~$ openssl verify -CAfile DOMAIN.wildcards.pem DOMAIN.wildcards.pem DOMAIN.wildcards.pem: OK elyograg@bilbo:~$ openssl version OpenSSL 1.1.1f 31 Mar 2020 Other bare metal systems and their results with the same PEM file: Verifies on Proxmox (the one running the VM) with openssl 1.1.1n Verifies on Ubuntu 22.04 with openssl 3.0.2 Fails on CentOS 7.5.1804 with openssl 1.0.2k-fips I also have the quictls fork of openssl on the VM, built from source, and it fails with exactly the same error message: [root@certs ~]# /usr/local/bin/qssl verify -CAfile /etc/ssl/certs/local/DOMAIN.wildcards.pem /etc/ssl/certs/local/DOMAIN.wildcards.pem C = US, O = Let's Encrypt, CN = R3 error 2 at 1 depth lookup: unable to get issuer certificate error /etc/ssl/certs/local/DOMAIN.wildcards.pem: verification failed [root@certs ~]# /usr/local/bin/qssl version OpenSSL 3.0.5+quic 5 Jul 2022 (Library: OpenSSL 3.0.5+quic 5 Jul 2022) --- I have redacted the domain name from the filename in what I pasted above, but everything else is untouched. The PEM file contains the server cert, the letsencrypt issuing cert, the private key, and generated dhparams. It works for most software that can handle PEM files for TLS. The only software I am sure about that utilizes the dhparams is haproxy. In case it matters, the server cert has a 4096 bit key. The certbot program is functioning correctly. Does anyone have any idea why this would fail in this way? Is there some information I can gather that would help with troubleshooting? The little evidence I have says it is failing on RPM distros and passing on DEB distros. But the sample size is way too small to adequately support that hypothesis. In the unlikely event this is an XY problem, here is the X: I am trying to set up a letsencrypt certificate creation/renewal system on the VM for work that I have running on my own server. One of the things that I have my script doing is validating the certificate file that it produces before it declares success. I would like the VM to do the same, but right now I can't because of this issue. Thanks, Shawn
Re: [EXTERNAL] RE: enforcing mutual auth from the client
On Fri, 2022-09-02 at 00:22 +, Wall, Stephen wrote: > > A compromised server could easily still request the client > > certificate, no? > > But as noted, even a compromised server can ask for client > > credentials and then > > Yes, that's true. If the intruder knew to do so. Also, a thief can > break your window and get into your car, so you might as well leave > them rolled down all the time. > > The question wasn't "Should I care that..." or "Is it a good idea > to...". It was "Can OpenSSL 3 do this". > > You really should be asking "Should I care that..." though. Security by policy is even weaker than security by obscurity. Don't let detection of this little "gotcha" lull you into a false sense of security, or even heightened security.
Re: Session ID is coming as NULL in openSSL 3.0.2 and TLS 1.2 version
On Fri, Sep 02, 2022 at 07:23:41AM +, Sethuraman Venugopal wrote: > The SSL session is getting created successfully, but the session ID is > coming as NULL, due to which the handshake is failing between the > client and server. Successful handshakes need not issue a non-empty session id. The server may not support resumption, or may support only ticket-based resumption and have no session cache. Absence of a session id is NOT a failure, and your code must not require one. https://datatracker.ietf.org/doc/html/rfc5077#section-3.4 > Please suggest me a solution for this issue. Don't require a session id. -- Viktor.
RE: enforcing mutual auth from the client
> From: openssl-users On Behalf Of Viktor > Dukhovni > > Of course this test should only be applied for a full handshake, reused > sessions > piggyback on the certificates exchanged in the original full handshake. Thank you, that helps. I have not enabled session cache, so that's not a concern. - Steve
Session ID is coming as NULL in openSSL 3.0.2 and TLS 1.2 version
Dear All, In our project below are the openssl and TLS version we are consuming it OpenSSL Version : OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) TLS Version : 1.2 Message Digest : SHA256 The SSL session is getting created successfully, but the session ID is coming as NULL, due to which the handshake is failing between the client and server. memcpy (&m_ServerChallenge[0], SSL_SESSION_get_id(SSL_get0_session((SSL *) m_pSsl), nullptr), CHALLENGE_LENGTH); The above is the code snippet used to get the SSL session ID and copy it onto a Challenge variable - Since the Session ID is coming as NULL the Challenge value is coming as "0" Below are the values logged for your reference. 01:21:14.369[1e64][Warning] SslNonCertificateConnectTransport : The pSsl Value is : [03B3A808] 01:21:14.369[1e64][Warning] SslNonCertificateConnectTransport : The SSL Session value SSL_get0_session((SSL *) m_pSsl) : [03B47B48] 01:21:14.369[1e64][Warning] SslNonCertificateConnectTransport : The Session ID is SSL_SESSION_get_id(SSL_get0_session((SSL *) m_pSsl), nullptr) : [] Please suggest me a solution for this issue. Kindlly let me know in case of any further inputs required. Regards, Sethu V
