cert/key config woes

2022-06-01 Thread Rob Sargent

This part always confuses me

I supply the trust and key store files on the command line and I see the 
SAN for the tomcat server IP (in ObjectId #3). I try to connect to 
tomcat by host-IP and port.  Here's the text of the keystore sent in.


   Keystore type: PKCS12
   Keystore provider: SUN

   Your keystore contains 1 entry

   Alias name: sgsagent
   Creation date: Jun 2, 2022
   Entry type: trustedCertEntry

   Owner: EMAILADDRESS=rob.sarg...@utah.edu,
   CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
   Utah, L=Salt Lake City, ST=UT, C=US
   Issuer: EMAILADDRESS=rob.sarg...@utah.edu,
   CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
   Utah, L=Salt Lake City, ST=UT, C=US
   Serial number: 2f543ea5b1ce847034a34dfb4d26ecbdac1959d5
   Valid from: Thu Jun 02 03:12:01 UTC 2022 until: Sat Jul 02 03:12:01
   UTC 2022
   Certificate fingerprints:
 SHA1:
   61:92:93:E7:A1:05:85:ED:66:6F:BC:6C:76:7E:CA:E8:7F:A7:0D:93
 SHA256:
   
23:85:E4:85:08:93:B1:4C:D7:40:47:E7:EF:3F:8F:5F:FC:FA:CA:57:0F:B1:4C:A8:3F:25:AE:D7:98:0C:4B:28
   Signature algorithm name: SHA256withRSA
   Subject Public Key Algorithm: 2048-bit RSA key
   Version: 3

   Extensions:

   #1: ObjectId: 2.5.29.35 Criticality=false
   AuthorityKeyIdentifier [
   KeyIdentifier [
   : F4 FC 13 D9 FC 1C C1 A0   DB 0A 81 28 C0 EF DC FF ...(
   0010: 28 64 81 BE    (d..
   ]
   ]

   #2: ObjectId: 2.5.29.19 Criticality=false
   BasicConstraints:[
  CA:true
  PathLen: no limit
   ]

   #3: ObjectId: 2.5.29.17 Criticality=false
   SubjectAlternativeName [
  IPAddress: 10.0.2.118
   ]

   #4: ObjectId: 2.5.29.14 Criticality=false
   SubjectKeyIdentifier [
   KeyIdentifier [
   : F4 FC 13 D9 FC 1C C1 A0   DB 0A 81 28 C0 EF DC FF ...(
   0010: 28 64 81 BE    (d..
   ]
   ]

but I get

   javax.net.ssl.SSLHandshakeException: No subject alternative names
   matching IP address 10.0.2.118 found
    at
   
java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:578)
    at
   
java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
    at
   edu.utah.camplab.sgs.AbstractSGSRun.canConnect(AbstractSGSRun.java:386)
    at
   edu.utah.camplab.sgs.AbstractSGSRun.init(AbstractSGSRun.java:296)
    at
   edu.utah.camplab.sgs.AbstractSGSOptions.init(AbstractSGSOptions.java:37)
    at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:76)
    at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:85)
    at edu.utah.camplab.app.SGSPValue.(SGSPValue.java:68)
    at edu.utah.camplab.app.SGSPValue.main(SGSPValue.java:27)
   Caused by: javax.net.ssl.SSLHandshakeException: No subject
   alternative names matching IP address 10.0.2.118 found
   Then comes my summary log:
   03:52:04.752 [main] ERROR edu.utah.camplab.sgs.AbstractSGSRun -
   cannot get to saver, trying 10.0.2.118:15002
   Could not establish connection to 10.0.2.118:15002
   from
    if (! canConnect() ) {
  logger.error("cannot get to saver, trying {}:{}",
   getAccumulationHost(), getAccumulationPort());
  throw new RuntimeException(String.format("Could not establish
   connection to %s:%d", getAccumulationHost(), getAccumulationPort()));
    }

  protected boolean canConnect() {
    boolean retval = false;
    String weburl = String.format("https://%s:%d;,
   getAccumulationHost(), getAccumulationPort());

    try {
  HttpRequest request = HttpRequest.newBuilder()
    .header("dbrole", getProjectName())
    .header("dbname", getDbName())
    .header("dbhost", System.getProperty("SGSSRVR_databaseHost",
   "localhost"))
    .uri(URI.create(weburl+"/sgs/webmonitor"))
    .build();
  HttpResponse response = getHttpClient().send(request,
   HttpResponse.BodyHandlers.ofString());
  retval = response.statusCode() == 200;
    }
    catch (IOException  | InterruptedException ie) {
  retval = false;
  ie.printStackTrace();
    }
    return retval;
  }


I had this overall configuration working until I 'terminated' the AWS 
server instance and am trying to rebuild.


Could a lack of network connectivity between client and server present 
this same symptom?


Re: FIPS Mode is not getting enabled in Tomcat9 using Openssl 3.0.2 post successful FIPS module installation in windows

2022-06-01 Thread Mark Thomas

On 01/06/2022 17:00, Christopher Schultz wrote:

Mark,

On 6/1/22 09:49, Mark Thomas wrote:

On 20/05/2022 12:43, Mark Thomas wrote:



Tomcat Native has not been updated for OpenSSL 3.0.x and FIPS. Code 
changes in Tomcat Native are going to be required to get this to work.


After doing some work on this I have an update.

First of all, OpenSSL 3 has not yet obtained FIPS certification. You 
can use the FIPS provider but it is not (yet) certified.


To use the OpenSSL 3 FIPS provider with Tomcat you need to do all of 
the following:

- build Tomcat Native 1.2.x with OpenSSL 3.x
- configure OpenSSL to use the FIPS provider by default
   https://www.openssl.org/docs/man3.0/man7/fips_module.html


If this is anything like OpenSSL 1.x, you will need to build OpenSSL 
with FIPS enabled to begin with. It's not just a runtime setting. (I 
don't claim to understand the fine details of FIPS, but IMHO it should 
have been possible for OpenSSL to be built in a standard way with FIPS 
operational mode being simply a runtime decision, but that isn't how 
OpenSSL did things... at least not originally.)


FIPS in 3.x is very different. Details are in the OpenSSL man page I 
linked above.



- DO NOT configure the APRLifecycleListener to use FIPS


Oh, that's interesting :)

Is that because the provider itself is FIPS and therefore there's no 
reason to have an API to specifically-enable it?


You can use it via API but it is possible to enable it entirely via 
configuration.


Is it possible to 
confirm from client code e.g. libtcnative that the module is indeed in 
FIPS mode?


You can confirm that the FIPS provider is the default provider which 
should be good enough.


This is why I asked earlier whether we wanted to add a confirmation 
check to each TLS connection to check that the selected cipher was from 
the FIPS provider.


Although you won't see any confirmation in the logs, Tomcat Native 
will be using the OpenSSL FIPS provider.


Updates are in progress so that:
- Tomcat will log a message on start when FIPS is the default provider
- setting the FIPSMode options when using OpenSSL 3 won't break things

The above will require Tomcat Native 1.2.34 onwards.


I think we might want to make a note of all this in the documentation 
for the APR lifecycle listener, including all the version information 
you have above.


The updates I have locally include most of that either in the docs or 
the change log.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: FIPS Mode is not getting enabled in Tomcat9 using Openssl 3.0.2 post successful FIPS module installation in windows

2022-06-01 Thread Christopher Schultz

Mark,

On 6/1/22 09:49, Mark Thomas wrote:

On 20/05/2022 12:43, Mark Thomas wrote:



Tomcat Native has not been updated for OpenSSL 3.0.x and FIPS. Code 
changes in Tomcat Native are going to be required to get this to work.


After doing some work on this I have an update.

First of all, OpenSSL 3 has not yet obtained FIPS certification. You can 
use the FIPS provider but it is not (yet) certified.


To use the OpenSSL 3 FIPS provider with Tomcat you need to do all of the 
following:

- build Tomcat Native 1.2.x with OpenSSL 3.x
- configure OpenSSL to use the FIPS provider by default
   https://www.openssl.org/docs/man3.0/man7/fips_module.html


If this is anything like OpenSSL 1.x, you will need to build OpenSSL 
with FIPS enabled to begin with. It's not just a runtime setting. (I 
don't claim to understand the fine details of FIPS, but IMHO it should 
have been possible for OpenSSL to be built in a standard way with FIPS 
operational mode being simply a runtime decision, but that isn't how 
OpenSSL did things... at least not originally.)



- DO NOT configure the APRLifecycleListener to use FIPS


Oh, that's interesting :)

Is that because the provider itself is FIPS and therefore there's no 
reason to have an API to specifically-enable it? Is it possible to 
confirm from client code e.g. libtcnative that the module is indeed in 
FIPS mode?


Although you won't see any confirmation in the logs, Tomcat Native will 
be using the OpenSSL FIPS provider.


Updates are in progress so that:
- Tomcat will log a message on start when FIPS is the default provider
- setting the FIPSMode options when using OpenSSL 3 won't break things

The above will require Tomcat Native 1.2.34 onwards.


I think we might want to make a note of all this in the documentation 
for the APR lifecycle listener, including all the version information 
you have above.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: FIPS Mode is not getting enabled in Tomcat9 using Openssl 3.0.2 post successful FIPS module installation in windows

2022-06-01 Thread Mark Thomas

On 20/05/2022 12:43, Mark Thomas wrote:



Tomcat Native has not been updated for OpenSSL 3.0.x and FIPS. Code 
changes in Tomcat Native are going to be required to get this to work.


After doing some work on this I have an update.

First of all, OpenSSL 3 has not yet obtained FIPS certification. You can 
use the FIPS provider but it is not (yet) certified.


To use the OpenSSL 3 FIPS provider with Tomcat you need to do all of the 
following:

- build Tomcat Native 1.2.x with OpenSSL 3.x
- configure OpenSSL to use the FIPS provider by default
  https://www.openssl.org/docs/man3.0/man7/fips_module.html
- DO NOT configure the APRLifecycleListener to use FIPS

Although you won't see any confirmation in the logs, Tomcat Native will 
be using the OpenSSL FIPS provider.


Updates are in progress so that:
- Tomcat will log a message on start when FIPS is the default provider
- setting the FIPSMode options when using OpenSSL 3 won't break things

The above will require Tomcat Native 1.2.34 onwards.

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org