Hello - We did this actually. But I can't be sure we did it correctly. We created a new key using the IP address as the host, and replaced the "a1as" aliased key in Glassfish. We loaded that certificate into the client. But we got the same error.
I did not look at the certificate to see if altSubjectNames was there though. There does not seem to be a way to add altSubjectNames if it is not present... At this point we have given up. It is simpler to avoid Tomcat completely and make the call from a Glassfish server on the client box. After importing the server's "a1as" certificate into the client Glassfish keystore, with an alias of the server's IP address, the call works perfectly. Thanks On Fri, Aug 14, 2009 at 2:37 AM, Ognjen Blagojevic<ogn...@etf.bg.ac.rs> wrote: > (IANA certificate expert) > > It is not clear to me do you have control over Glassfish server or not. > > If you do, just generate self-signed certificate for the Glassfish one more > time, giving IP address instead of FQDN for CN. > > If you don't, than you need to check does certifiate have altSubjectNames: > > openssl x509 -in my.crt -noout -text > > Here is the example of certifcate that does have them: > > ---- > Certificate: > [snip] > Subject: CN=test.eonis.net, > [snip] > X509v3 Subject Alternative Name: > DNS:test.eonis.net, DNS:test.eonis.org, DNS:*.co.uk > [snip] > ---- > > Again, if there are alternative names in the sertificate, check if the IP > address of the server is listed. But, according to your previous posts, I > beleive it is not. > > If there are not alternative names (host names or IP addresses), than if you > can't use CN in your URL, your last resort is to try to force your client to > use that certificate even though that is problematic from security > standpoint. > > Read this document for example how to do that: > > > http://www.contentroller.com/c/view/7236/no_subject_alternative_names_matching_ip_address_no_name_matching_found.html > > Regards, > Ognjen > > > > Jeff Sexton wrote: >> >> Hello - >> >> We do not have permission to create a hosts file entry (that was my >> first idea). >> >> We also do not need both IP address and host name to work at the same >> time, just the IP address. Our problem seems to be that the Tomcat >> client wants to find a certificate by hostname, even when the URL >> requested is by IP address, and a certificate has been imported with >> an alias of that IP address. >> >> I looked at the "a1as" certificate extracted from Glassfish and it >> does indeed have a host name in the CN field. If this is when it can >> not be used to validate a call by IP address, then why does importing >> it with an alias of the IP address not work for us? >> >> >> Thank you, my understanding of this is still weak. >> >> >> On Thu, Aug 13, 2009 at 8:47 AM, Ognjen Blagojevic<ogn...@etf.bg.ac.rs> >> wrote: >>> >>> Jeff Sexton wrote: >>>> >>>> We have a situation where we need to call a SOAP service in a >>>> Glassfish server via HTTPS from a servlet in Tomcat. We extract a >>>> self-signed certificate from Glassfish and imported it on the Tomcat >>>> server. It all works in situations where we can use the >>>> fully-qualified host name in the request and in the alias of the >>>> certificate when importing on the Tomcat server. >>>> >>>> But we need to operate in an environment with a name service. When we >>>> try to use the IP address of the Glassfish server in the HTTPS call >>>> and in the certificate alias, the call fails with a "no subject >>>> alternate name" exception. >>>> >>>> In Glassfish to Glassfish calls, using the IP address works fine. >>>> >>>> Does anyone know how to make an SSL call from a Tomcat server using >>>> the IP address only? Is it even possible? >>> >>> I'm not 100% sure, but I think it is not possible. >>> >>> Your server certificate have Common Name (CN) which can match either FQDN >>> (server.company.com) or IP (123.123.123.123) - not both. >>> >>> You can, however, try to workaround your inability to contact DNS server >>> by >>> manually inserting the adress to the "hosts" file, if you have permission >>> to >>> do that. >>> >>> Regards, >>> Ognjen >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Jeff Sexton http://www.elgintime.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
