WSA SSH connection to a Tomcat instance set to "require

Hi Tim,

Yes, it is possible, just not simple.   The detailed client side instructions will depend on what type of client you have.   In general the client will have to:

1) create a set of keys

2) obtain a signed certificate by CA by supplying them with the public key

3) configure the client to connect to the WSA's server using HTTPS and supply the configuration options for where the client's private key is, where the client's digital certificate is, and what the password is to the client's private key

4) The server side will need a copy of the CA's certificate so that it can validate the client's certificate when it is received by the server

Have you changed the WSA's web.xml to specify a security constraint that requires a HTTPS connection?   Otherwise the web application will accept either HTTP or HTTPS.

That help?

Mike J.

It helps as it confirms most of what I've already done.

I've got 11.3 as the client and the server, I've got the cert loaded in both the client and the server.

When I change the Tomcat config from "optional" to "require" I'm getting SSH errors on the 11.3 client side of the application. If I leave it as "optional" it works fine, as long as I've imported the correct cert into the registry.

I should add the cert was generated using OpenSSH, and it's self-signed.

Ok.  Here is where the client type comes in.   When you say "I've got 11.3 as the client...", I can assume your WSA SOAP client is an OpenEdge ABL client.  Tell me if I've made a bad assumption.

ABL client connections to a SOAP (web service) will not support SSL client authentication until release 11.4.   Starting in 11.4 there are additional CONNECT options that turn on SSL client authentication, locate the private key file, locate the certificate file, and provide the private key file's password.

If you are going to support self-signed certificates - Tomcat's trustStore will have to be configured so that it can validate them.  

Mike J.

Yes, I'm using 11.3's SOAP interface, so it looks like I'll need 11.4 to get this working.

Wrt "truststore" - this is what I've got in the Tomcat config for loading certs - should I be looking into something else?

   <Connector port="9443"

protocol="HTTP/1.1"

SSLEnabled="true"

maxThreads="150"

scheme="https"

secure="true"

clientAuth="false"

sslProtocol="TLS"

SSLCertificateFile="D:\tomcat\keystore\openssl\server.crt"

SSLCertificateKeyFile="D:\tomcat\keystore\openssl\server.key"

SSLVerifyClient="optional"

/>

You are looking at adding to Tomcat connector:   SSLCACertificatePath="<path>"

That is where the APR module will look for CA certificates to use in validating the client's certificate during client authentication.

Since you are using APR, the CA certificate storage is the same format as is used in $DLC/certs.   Never tried it, but you could try pointing to $DLC/certs and see if any dark smoke indicates a problem.

While trying this, you should ensure that hitting the WSA URL with HTTP is either redirected by Tomcat to use HTTPS or a failure is returned.   Just saying...

I'll give this a try and check for "dark smoke".

I'll make sure to set the fire dept on speed dial first. :)

Actually, the server side is only using Tomcat for the certs. I'm testing the client and server side on the same machine, so the OE install has the cert installed on both sides. When I go to deploy this I'm not _expecting_ to add the cert to the OE install, as I'm not planning on having anything call an OE service besides the Tomcat stuff. Will this be an issue?

No, you are doing the right steps.   You need to focus on the SOAP client and the Tomcat server.   The backend OE AppServer is probably safe enough.

I was simply trying to point out that the Tomcat APR connector uses OpenSSL, as does OpenEdge.   Therefore, the key, certificate, and CA management would be approximately the same.