<div dir="ltr"><div>Hello,</div><div><br></div><div>I was wondering if there was any effort to make progress in separating the SECLEVEL directive into AUTHSECLEVEL and TLSSECLEVEL as described in $openssl/ssl/ssl_cert.c's ssl_verify_cert_chain() function.  I found a post from 2016 on this mailing list about this:</div><div><br></div><a href="https://mta.openssl.org/pipermail/openssl-users/2016-May/003768.html">https://mta.openssl.org/pipermail/openssl-users/2016-May/003768.html</a><br><div><br></div><div>I have a use case where I need to enable Mutual TLS authentication for hardware clients that have immutable manufacturer-signed certificates.  Some of those certificates are signed with MD5, but I don't know which ones beforehand, and I'd rather not have SECLEVEL=0 compromise the allowable ciphers in the TLS connection.</div><div><br></div><div>[re MD5 insecurity in auth: I already have application-layer authentication (e.g. HTTPS Bearer auth), and I'm not looking to replace that with Mutual TLS - I do need to opportunistically gather other information from the client certs though.]</div><div><br></div><div>In the meantime, if my only option is to use SECLEVEL=0, I think I'd need to do some application-layer enforcement of TLS parameters.  I suppose I could enforce ciphers by using SSL_get_cipher_name().  Are there other parameters that you recommend I enforce at the application layer?  Is it possible to reach parity with "SECLEVEL=1" behavior this way?  Are there any other downsides or issues to be aware of with this approach?</div><div><br></div><div>Many thanks!</div><div><br></div><div>Armen</div></div>