Thanks for the JIRA account. I have just created the issue ( https://issues.apache.org/jira/browse/SOLR-18270). I am working on the pull requests.
Jean-Marie Le ven. 29 mai 2026 à 12:37, Jan Høydahl <[email protected]> a écrit : > I approved your JIRA request. Thanks for contributing a fix. That will be > really helpful! > > Jan > > > 29. mai 2026 kl. 09:38 skrev Jean-Marie HEITZ <[email protected]>: > > > > I prepared two branches, one with the simple adjustment ( > > https://github.com/heitzjm/solr/tree/CERT_AUTH_PLUGIN_EASY) and another > > which expose a parameter ( > > > https://github.com/heitzjm/solr/tree/CERT_AUTH_PLUGIN_REQUEST_ATTRIBUTE_PARAM > ). > > I applied for a Jira account a few hours ago, so I guess it is just a > > matter of time until I am able to open an issue and then make a PR > > referencing the issue. > > > > Le jeu. 28 mai 2026 à 20:47, Gus Heck <[email protected]> a écrit : > > > >> That sounds like a bug. Creating a JIRA and a PR would be helpful if you > >> are able. > >> > >> On Thu, May 28, 2026 at 5:43 AM Jean-Marie HEITZ <[email protected]> > >> wrote: > >> > >>> Good morning, > >>> > >>> While trying to migrate from SOLR 9 to 10 using the official Docker > >> images, > >>> I noticed that authentication using SSL certificates did not work > >> anymore. > >>> I found out that, as I was using SOLR_SSL_NEED_CLIENT_AUTH, and that > the > >>> SSL connection level does work and is established, the request > attribute > >>> that carries the client cert is not > >>> "javax.servlet.request.X509Certificate" anymore in jetty-12, which is > >> used > >>> in the Official SOLR Docker image : it > >>> became "jakarta.servlet.request.X509Certificate". I tested the > attribute > >>> change by building SOLR and the Docker Image from source : it worked. > So > >> I > >>> guess it might be good to change, or add a parameter to be able to > >>> configure the lookup attribute in security.json. > >>> Can someone have a look ? > >>> > >>> Besides that, I also tried the CertAuthPlugin User Principal > Extraction , > >>> and noticed something strange with the "subject.dn" path : the order of > >> the > >>> components in the Distinguished Name was not the same as the default > >>> method. In detail : > >>> - openssl x509 -text outputs O, OU and then CN for the SSL certificate > >>> - CertAuthPlugin.DEFAULT_PRINCIPAL_RESOLVER gives CN, OU, O > >>> - Extraction with "subject.dn" gives CN, O, OU > >>> I assume the Role Based Authorization Plugin uses the principal > >> extraction > >>> as a string, so the order of the elements does matter. However, I > haven't > >>> investigated this behavior further yet. > >>> > >>> Thanks > >>> > >>> Jean-Marie Heitz > >>> > >> > >> > >> -- > >> http://www.needhamsoftware.com (work) > >> https://a.co/d/b2sZLD9 (my fantasy fiction book) > >> > >
