Hi Marc, thanks for your reply.<div><br></div><div>I got this working, so I'll describe what I did in case it helps anyone in the future.</div><div><br></div><div>My use case is a bit contrived. In my application protocol, I get a client hostname string. The application includes this value because the connection need not always use SSL client authentication. In my implementation, SSL client auth is mandatory, so I don't really need to make this check (I can just look at the client cert directly and ignore this value). That said, I decided I'd make sure the certificate and the application layer match for the sake of additional paranoia. Regardless, the following information would be useful.</div>
<div><br></div><div><div>In my PipelineFactory, I created my SSLEngine and added it to the pipeline. I also passed a reference to the engine up to my HTTP RequestHandler.</div></div><div><br></div><div>You can call sslEngine.getSession().getPeerCertificates(); to get an array containing the trusted certificate path used to authenticate the client. Element 0 is the client's certificate. If the certificate is an X509Certificate, you can use the sun.security.util.HostnameChecker.match(String hostname, X509Certificate cert) to compare a hostname string to a certificate. I assume that this is what Java uses to authenticate the connection in the first place. I feel somehow sneaky using this class but it is public.</div>
<div><br></div><div>Hope that helps (and doesn't hinder) someone in the future.</div><div><br></div><div>Cheers,</div><div>Mat</div><div><br><div class="gmail_quote">2010/12/23 Marc-André Laverdičre <span dir="ltr"><<a href="mailto:marcandre.laverdiere@gmail.com">marcandre.laverdiere@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Normally, the default java SSL implementation does DNS resolution and reverse lookups. You just need to have a trust store.</p>
<p></p><blockquote type="cite"><div><div></div><div class="h5">On 21 Dec 2010 03:58, "Mathew Johnston" <<a href="mailto:mjohnston@capsaicin.ca" target="_blank">mjohnston@capsaicin.ca</a>> wrote:<br><br>Hi,<div>
<br></div><div>I'm implementing a protocol that depends on SSL for client authentication. The application messages (over SOAP) contain a machine name. The requirement I have is to validate the machine name in the message against the machine name listed in the client certificate used for authentication at the SSL layer. Is this possible? What's the best way to do this?</div>
<div><br></div><div>I'm assuming so far that I want to compare against the results of SSLEngine.getPrincipal(); is this correct? At my application layer (HttpRequestHandler), I don't have a reference to the SSLEngine used by the SSLHandler. Is it a good idea to simply pass my HttpRequestHandler's constructor a reference to the SSLEngine instance I'm using to construct the SSLHandler (this would of course be in my PipelineFactory)? </div>
<div><br></div><div>Is there another method that's preferable?</div><div><br></div><div>Since the certificates are all hostname based, I'm assuming that the SSL layer does the appropriate name resolution to authenticate the client. Is this also correct? Or, do I need to implement my own TrustManager to do the lookup and check against the principal?</div>
<div><br></div><div>Cheers,</div><div>Mathew Johnston</div>
<br></div></div>_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org" target="_blank">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br></blockquote><p></p>
<br>_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br></blockquote></div><br></div>