Did I cause that problem because I remember there being a bug request
because we weren’t applying the Need and Want from the Impl config.
On Fri, Apr 1, 2022 at 10:55 AM Emmanuel Lécharny <elecha...@gmail.com>
wrote:
> Got it !!!
>
> What a nasty bug it was...
>
> The new SslFilter.createEngine() method was doing:
>
> protected SSLEngine createEngine(IoSession session, InetSocketAddress
> addr) {
> SSLEngine sslEngine = (addr != null) ?
> sslContext.createSSLEngine(addr.getHostString(), addr.getPort())
> : sslContext.createSSLEngine();
> sslEngine.setNeedClientAuth(needClientAuth);
> sslEngine.setWantClientAuth(wantClientAuth);
> ...
>
> And in SslEngineImpl :
>
> public synchronized void setNeedClientAuth(boolean need) {
> conContext.sslConfig.clientAuthType =
> (need ? ClientAuthType.CLIENT_AUTH_REQUIRED :
> ClientAuthType.CLIENT_AUTH_NONE);
> }
>
> plus
>
> public synchronized void setWantClientAuth(boolean want) {
> conContext.sslConfig.clientAuthType =
> (want ? ClientAuthType.CLIENT_AUTH_REQUESTED :
> ClientAuthType.CLIENT_AUTH_NONE);
> }
>
> when you set Need & Want, the later wins. Here, I had Need but not Want,
> so it ends with ClientAuthType.CLIENT_AUTH_NONE :/
>
> You can't have both, you need to pick the one that has to be set and
> ignore the other. In MINA 2.1.5, we have :
>
> // Those parameters are only valid when in server mode
> if (sslFilter.isWantClientAuth()) {
> sslEngine.setWantClientAuth(true);
> }
>
> if (sslFilter.isNeedClientAuth()) {
> sslEngine.setNeedClientAuth(true);
> }
>
> which only call the proper setting. Of course, if you set both to true,
> you'll end with NEED, which is just fine.
>
> On 01/04/2022 16:18, Emmanuel Lécharny wrote:
> > Some progress:
> >
> > With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
> > clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
> > set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
> > sent to the client.
> >
> > Now to understand why this flag is improperly set...
> >
> > On 01/04/2022 11:06, Emmanuel Lécharny wrote:
> >> Still fighting...
> >>
> >> When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
> >> that is not using MINA) sends a client Certificate to the server after
> >> having received a CertificateRequest:
> >>
> >> javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
> >> CEST|CertificateRequest.java:692|Consuming CertificateRequest
> >> handshake message (
> >> "CertificateRequest": {
> >> "certificate types": [ecdsa_sign, rsa_sign, dss_sign]
> >> "supported signature algorithms": [ecdsa_secp256r1_sha256,
> >> ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
> >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
> >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
> >> rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
> >> rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
> >> "certificate authorities": [CN=ftpserver, CN=ftpclient]
> >> }
> >> )
> >> ...
> >> javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
> >> CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake
> >> message (
> >> <empty>
> >> )
> >> javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
> >> CEST|CertificateMessage.java:330|Produced client Certificate handshake
> >> message (
> >> "Certificates": [
> >> "certificate" : {
> >> "version" : "v3",
> >> "serial number" : "60 38 4B B4",
> >> "signature algorithm": "SHA256withRSA",
> >> "issuer" : "CN=ftpclient",
> >> "not before" : "2021-02-26 02:15:32.000 CET",
> >> "not after" : "2031-02-26 02:15:32.000 CET",
> >> "subject" : "CN=ftpclient",
> >> "subject public key" : "RSA"}
> >> ]
> >> )
> >> ...
> >>
> >> With MINA 2.2.0, I don't see any CertificateRequest being sent by the
> >> server. Which I don't understand, because the NeedClientAuth flag is
> >> set to true...
> >>
> >>
> >> Still investigating
> >>
> >> On 31/03/2022 14:38, Emmanuel Lécharny wrote:
> >>> Ok, pb fixed with an added filter.
> >>>
> >>> Now, I still get a NPE while trying to access the peerCertificate
> >>> from the session, even after the Handshake has been completed...
> >>>
> >>> On 30/03/2022 18:02, Emmanuel Lécharny wrote:
> >>>> Hi Jonathan,
> >>>>
> >>>> no, it's just that we try to send a clear text message after having
> >>>> set the SSLFilter, pretty much as what we had to workaround in
> >>>> Directory. I'm going to fix that.
> >>>>
> >>>> On 25/03/2022 19:48, Jonathan Valliere wrote:
> >>>>> Are you trying to get the peer cert after the filter emits the
> >>>>> connected
> >>>>> after the handshake completes? If you do it too early it won’t
> >>>>> populate.
> >>>>>
> >>>>> On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny
> >>>>> <elecha...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi!
> >>>>>>
> >>>>>> following the effort put in rewriting the Sslfilter (and all the
> >>>>>> inner
> >>>>>> code) by Jonathan lately, I would like to know if we could mive
> >>>>>> forward
> >>>>>> with an alpha version of this work.
> >>>>>>
> >>>>>> I have tested it with Apache LDAP API and Apache Directory Server,
> >>>>>> with
> >>>>>> success. I still have some work to do
> <https://www.google.com/maps/search/%3E+success.+I+still+have+some+work+to+do+?entry=gmail&source=g>on
> FtpServer to have it working
> >>>>>> with 2.2.X, we get some NPE when trying to fetch the peer
> certificate
> >>>>>> from the SSLSession (for some unkown reason, when I call
> >>>>>> sslSession.getPeerCertiticate() it returns null).
> >>>>>>
> >>>>>> Wdyt ?
> >>>>>> --
> >>>>>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> >>>>>> <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail&source=g>
>
> >>>>>>
> >>>>>> T. +33 (0)4 89 97 36 50
> >>>>>> P. +33 (0)6 08 33 32 61
> >>>>>> emmanuel.lecha...@busit.com https://www.busit.com/
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >>>>>> For additional commands, e-mail: dev-h...@mina.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>
