Re: SSL Cert install help.

[Christopher Schultz]

Bill,

On 9/22/23 13:25, Bill wrote:

Hello All,
  I may have started my SSL Cert install & config at step 2 instead of
step 1... :-(


Most mistakes are recoverable :)


Basically I have created my key store, my p12 file and have my cert all in
a sub directory of the conf directory.


All of those things are usually in the same file. What files do you 
actually have, and what is in each of them, specifically? If you have a 
keystore of any kind (including p12 files), post the output of:


$  keytool -list -keystore [filename]


I have updated the server xml with my connectors per online directions.
Yet my SSL (https) cert/site doesn't work.


Can you please post your  configuration, replacing any secrets?

Also, what do you mean "doesn't work"? Tomcat does not start? 
Connections are refused? Browser doesn't like server's cert? Can't 
complete handshake?



The catalina logs do not provide a whole lot of help for me as a TC novice.
I did see this in the log:

(org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache
Tomcat Native library which allows using OpenSSL was not found on the
java.library.path: [/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib])


This is a warning. If you don't intend to use tcnative, you can disable 
the AprLifecycleListener and it will no longer emit that message.



but I'm pretty sure I didn't install native, but the regular version of TC.


The "native" connector is just a Connector, not all of Tomcat. The 
"regular" version of Tomcat supports several types of connectors, the 
"native" one included.



So my question is, was I supposed to install or turn something on before
beginning the process of key store and p12 file and connector configuration?


No, if you have your keystore in order and refer to it properly in the 
config then that's all you should need.


-chris

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

Re: SSL issue

[John Dale (DB2DOM)]

Noted - excellent!

On 3/18/23, Kevin Huntly  wrote:
> I was able to read the keystore with both openssl and keytool, but for some
> reason the private key within the pkcs#12 file had a different password
> than the keystone password. I ended up just rebuilding the cert and the
> keystore, and it's working now. Thanks !
> 
>
> Kevin Huntly
> Email: kmhun...@gmail.com
> Cell: 716/424-3311
> 
>
> -BEGIN GEEK CODE BLOCK-
> Version: 1.0
> GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
> W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
> PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
> G++ e(+) h--- r+++ y+++*
> --END GEEK CODE BLOCK--
>
>
> On Sat, Mar 18, 2023 at 3:27 PM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
>
>> Hello,
>>
>> the relevant error is:
>> Caused by: javax.crypto.BadPaddingException: Given final block not
>> properly padded. Such issues can arise if a bad key is used during
>> decryption.
>>
>> It seems there is something wrong with your keystore.
>> Are both, private and public key in the p12 file?
>> Can you check the contents with keytool?
>> Alternatively, you can also use pem files, they are more readable than
>> p12.
>>
>> Greetings, Thomas
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Kevin Huntly 
>> > Gesendet: Samstag, 18. März 2023 19:15
>> > An: users@tomcat.apache.org
>> > Betreff: SSL issue
>> >
>> > Hello Everyone,
>> >
>> > I'm having an issue with my SSL connector:
>> >
>> > 
>> > 18-Mar-2023 14:12:46.996 SEVERE [main]
>> > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
>> > to
>> > initialize component
>> [Connector[org.apache.coyote.http11.Http11Nio2Protocol-
>> > 8443]]
>> > org.apache.catalina.LifecycleException: Protocol handler
>> initialization
>> > failed
>> > at
>> > org.apache.catalina.connector.Connector.initInternal(Connector.java:1014)
>> > at
>> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
>> > at
>> >
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549
>> > )
>> > at
>> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
>> > at
>> >
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1032)
>> > at
>> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
>> > at
>> > org.apache.catalina.startup.Catalina.load(Catalina.java:724)
>> > at
>> > org.apache.catalina.startup.Catalina.load(Catalina.java:746)
>> > at
>> >
>> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMeth
>> > odHandleAccessor.java:104)
>> > at
>> > java.base/java.lang.reflect.Method.invoke(Method.java:578)
>> > at
>> > org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
>> > at
>> > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
>> > Caused by: java.lang.IllegalArgumentException: Get Key failed:
>> > Given final block not properly padded. Such issues can arise if a bad
>> key is used
>> > during decryption.
>> > at
>> > org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.createSSLContext(AbstractJsse
>> > Endpoint.java:107)
>> > at
>> > org.apache.tomcat.util.net
>> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoi
>> > nt.java:71)
>> > at
>> > org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:146)
>> > at
>> > org.apache.tomcat.util.net
>> .AbstractEndpoint.bindWithCleanup(AbstractEndpoin
>> > t.java:1302)
>> > at
>> > org.apache.tomcat.util.net
>> .AbstractEndpoint.init(AbstractEndpoint.java:1315)
>> > at
>> > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:652)
>> > at
>> >
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.j
>> > ava:75)
>> > at
>> > org.apache.catalina.connector.Connector.initInternal(Connector.java:1012)
>> > ... 11 more
>> > Caused by: java.security.UnrecoverableKeyException: Get Key
>> failed:
>> > Given final block not properly padded. Such issues can arise if a bad
>> key is used
>> > during decryption.
>> > at
>> >
>> java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.j
>> > ava:454)
>> > at
>> >
>> java.base/sun.security.util.KeyStoreDelegator.engineGetKey(KeyStoreDelegator
>> > .java:91)
>> > at
>> > java.base/java.security.KeyStore.getKey(KeyStore.java:1077)
>> > at
>> > org.apache.tomcat.util.net
>> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:353)
>> > at
>> > org.apache.tomcat.util.net
>> .SSLUtilBase.createSSLContext(SSLUtilBase.java:246)
>> > at
>> 

Re: SSL issue

[John Dale (DB2DOM)]

What kind of key are you using?

I generate my certs with certbot.

The result needs to be converted thusly to be used:
openssl pkcs12 -export -out mykey-bundle.pfx -inkey myprivkey.pem -in
cert.pem -certfile chain.pem -password
pass:superdupersecretnoteventhealiensknow

Is this a possible source of the issue?


On 3/18/23, Kevin Huntly  wrote:
> Hello Everyone,
>
> I'm having an issue with my SSL connector:
>
> 
> 18-Mar-2023 14:12:46.996 SEVERE [main]
> org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> initialize component
> [Connector[org.apache.coyote.http11.Http11Nio2Protocol-8443]]
> org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1014)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1032)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:724)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:746)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at
> java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
> Caused by: java.lang.IllegalArgumentException: Get Key failed:
> Given final block not properly padded. Such issues can arise if a bad key
> is used during decryption.
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:107)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71)
> at
> org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:146)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1302)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1315)
> at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:652)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1012)
> ... 11 more
> Caused by: java.security.UnrecoverableKeyException: Get Key failed:
> Given final block not properly padded. Such issues can arise if a bad key
> is used during decryption.
> at
> java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:454)
> at
> java.base/sun.security.util.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:91)
> at
> java.base/java.security.KeyStore.getKey(KeyStore.java:1077)
> at
> org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:353)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:246)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:105)
> ... 18 more
> Caused by: javax.crypto.BadPaddingException: Given final block not
> properly padded. Such issues can arise if a bad key is used during
> decryption.
> at
> java.base/com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:861)
> at
> java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:941)
> at
> java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:734)
> at
> java.base/com.sun.crypto.provider.PBES2Core.engineDoFinal(PBES2Core.java:310)
> at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2207)
> at
> java.base/sun.security.pkcs12.PKCS12KeyStore.lambda$engineGetKey$0(PKCS12KeyStore.java:370)
> at
> java.base/sun.security.pkcs12.PKCS12KeyStore$RetryWithZero.run(PKCS12KeyStore.java:257)
> at
> java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:361)
> ... 23 more
> 
>
> And my SSL config:
>
> 
>  protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> address="0.0.0.0" port="8443" maxHttpHeaderSize="8192"
> maxThreads="150" minSpareThreads="25" 

Re: SSL issue

[Kevin Huntly]

I was able to read the keystore with both openssl and keytool, but for some
reason the private key within the pkcs#12 file had a different password
than the keystone password. I ended up just rebuilding the cert and the
keystore, and it's working now. Thanks !


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Sat, Mar 18, 2023 at 3:27 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> the relevant error is:
> Caused by: javax.crypto.BadPaddingException: Given final block not
> properly padded. Such issues can arise if a bad key is used during
> decryption.
>
> It seems there is something wrong with your keystore.
> Are both, private and public key in the p12 file?
> Can you check the contents with keytool?
> Alternatively, you can also use pem files, they are more readable than p12.
>
> Greetings, Thomas
>
> > -Ursprüngliche Nachricht-
> > Von: Kevin Huntly 
> > Gesendet: Samstag, 18. März 2023 19:15
> > An: users@tomcat.apache.org
> > Betreff: SSL issue
> >
> > Hello Everyone,
> >
> > I'm having an issue with my SSL connector:
> >
> > 
> > 18-Mar-2023 14:12:46.996 SEVERE [main]
> > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> > initialize component
> [Connector[org.apache.coyote.http11.Http11Nio2Protocol-
> > 8443]]
> > org.apache.catalina.LifecycleException: Protocol handler
> initialization
> > failed
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:1014)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> >
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549
> > )
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> >
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1032)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> > at
> > org.apache.catalina.startup.Catalina.load(Catalina.java:724)
> > at
> > org.apache.catalina.startup.Catalina.load(Catalina.java:746)
> > at
> >
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMeth
> > odHandleAccessor.java:104)
> > at
> > java.base/java.lang.reflect.Method.invoke(Method.java:578)
> > at
> > org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
> > at
> > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
> > Caused by: java.lang.IllegalArgumentException: Get Key failed:
> > Given final block not properly padded. Such issues can arise if a bad
> key is used
> > during decryption.
> > at
> > org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsse
> > Endpoint.java:107)
> > at
> > org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoi
> > nt.java:71)
> > at
> > org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:146)
> > at
> > org.apache.tomcat.util.net
> .AbstractEndpoint.bindWithCleanup(AbstractEndpoin
> > t.java:1302)
> > at
> > org.apache.tomcat.util.net
> .AbstractEndpoint.init(AbstractEndpoint.java:1315)
> > at
> > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:652)
> > at
> >
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.j
> > ava:75)
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:1012)
> > ... 11 more
> > Caused by: java.security.UnrecoverableKeyException: Get Key
> failed:
> > Given final block not properly padded. Such issues can arise if a bad
> key is used
> > during decryption.
> > at
> >
> java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.j
> > ava:454)
> > at
> >
> java.base/sun.security.util.KeyStoreDelegator.engineGetKey(KeyStoreDelegator
> > .java:91)
> > at
> > java.base/java.security.KeyStore.getKey(KeyStore.java:1077)
> > at
> > org.apache.tomcat.util.net
> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:353)
> > at
> > org.apache.tomcat.util.net
> .SSLUtilBase.createSSLContext(SSLUtilBase.java:246)
> > at
> > org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsse
> > Endpoint.java:105)
> > ... 18 more
> > Caused by: javax.crypto.BadPaddingException: Given final block
> 

Re: SSL configuration for Tomcat 9

[Christopher Schultz]

Vince,

On 7/15/22 19:56, Vince Stewart wrote:

My system uses embedded Tomcat to connect to a HttpServlet instance.
I have just uprgraded from Tomcat 8.0.2 to 9.0.64
I am implementing SSL for the first time.

I created a keystore with no alias. Keytool gave it the alias "mykey". (2nd
entry below)
I imported an issued PEM certificate (4 items in chain)
The final item in the chain has the alias "tomcat" as per
https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Importing_the_Certificate
(The same documentation recommends the keystore alias also be 'tomcat' but
If the keystore and the issued certificate are both given the same alias
(ie 'tomcat'), keytool will import the final entry as "self generated" and
throw an error. Here is my abbreviated keystore list using alias 'mykey'
for the keystore.


You have to import the signed cert on top of the one that already 
exists. Because you used "mykey" as the alias for the key/cert 
initially, you must use the same alias when you import the signed cert. 
Your self-signed cert will be replaced with the signed one. Remove the 
"tomcat" one and tell Tomcat to use "mykey".


Remember to make a backup ;)

I hate keystores.

-chris


keystore listing___
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 5 entries
intermediate, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256):
68:B9:C7:61.
intermediate2, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256):
7F:A4:FF:68
mykey, 16/07/2022, PrivateKeyEntry,
Certificate fingerprint (SHA-256):
36:F8:64:73:.
root, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256): D7:A7:A0:FB..
tomcat, 16/07/2022, trustedCertEntry,
Certificate fingerprint (SHA-256):
36:A9:B7:A9:..


Here is my startup code (no server.xml file)


 Tomcat tomcat = new Tomcat();
 tomcat.setPort(PATHS.getPortNumber());
 Connector c=tomcat.getConnector();
 c.setSecure(true);
 c.setScheme("https");
 c.setProperty("SSLEnabled","true");//crucial bit of code
 SSLHostConfig ss=new SSLHostConfig();
 //ss.setHostName("localhost"); this breaks the init process - leave as
"_default_"
 ss.setCertificateKeyAlias("mykey");   // if set to 'tomcat'
init will throw "Alias name [tomcat] does not identify a key entry"
 ss.setCertificateKeystorePassword("changit");
 ss.setCertificateKeystoreFile(PATHS.getHomePath()+"/ks/mykeystor.jks");
 ss.setCertificateKeystoreType("PKCS12");
 ss.setCertificateKeystoreProvider("SUN")
 c.addSslHostConfig(ss);
 org.apache.catalina.Context ctx = tomcat.addContext("", new
File(".").getAbsolutePath());
 Tomcat.addServlet(ctx, "myApp", new MyApp());
 ctx.addServletMappingDecoded("/*", "myApp");
 Logr.s("connector scheme "+c.getScheme());
 Logr.s("connector SSLEnabled "+c.getProperty("SSLEnabled"));
 Logr.s("connector redirect "+c.getRedirectPort()); //defaults to 443
 Logr.s("connector protocol "+c.getProtocol());
 tomcat.start();
 tomcat.getServer().await();

When I use "tomcat" as the alias for the keystore I cannot load the final
issued certificate without an error. If I use "mykey" as the keystore alias
everything seems to be working but the certificate returned to the browser
is not the domain-specific certified certificate but a certificate
generated with the certificate keystore fingerprint.  In a properly
operating implementation, what certificate should be returned to the
browser?
I'm obviously doing something wrong. But what ?


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

RE: SSL handshake failure logs required for auditing purpose

[jonmcalexander]

Tre's Bueno!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Mark Thomas 
> Sent: Thursday, July 7, 2022 1:22 PM
> To: users@tomcat.apache.org
> Subject: Re: SSL handshake failure logs required for auditing purpose
> 
> The next release (9.0.65) will have a dedicated logger for TLS handshake
> failures. You will be able to configure it like any other logger - including
> directing it to a dedicated file.
> 
> Mark
> 
> 
> On 07/07/2022 17:11, Ragavendhiran Bhiman (rabhiman) wrote:
> > Hi All,
> >
> > I require your kind help in logging the SSl connection failure logs 
> > including iP
> in the tomcat, Is there any best way to do It without performance impact
> other than -Djava.net debugs in jdk, is there any direct way from tomcat? Or
> any way we can derive any class from JSSE extension classes and add
> HandShakeListener while using the connectors. All our SSL connections are
> going through connectors. So kindly need your help how to log those SSL
> connection auditing logs through best method.
> > Thanks a lot in advance.
> >
> > Regards,
> > Raghav
> >
> >
> 
> -
> 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

Re: SSL handshake failure logs required for auditing purpose

[Mark Thomas]

The next release (9.0.65) will have a dedicated logger for TLS handshake 
failures. You will be able to configure it like any other logger - 
including directing it to a dedicated file.


Mark


On 07/07/2022 17:11, Ragavendhiran Bhiman (rabhiman) wrote:

Hi All,

I require your kind help in logging the SSl connection failure logs including 
iP in the tomcat, Is there any best way to do It without performance impact 
other than -Djava.net debugs in jdk, is there any direct way from tomcat? Or 
any way we can derive any class from JSSE extension classes and add 
HandShakeListener while using the connectors. All our SSL connections are going 
through connectors. So kindly need your help how to log those SSL connection 
auditing logs through best method.
Thanks a lot in advance.

Regards,
Raghav




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

Re: SSL handshake failure logs required for auditing purpose

[Ragavendhiran Bhiman (rabhiman)]

Version of tomcat used 9.0.x.
Kindly help on the ssl logging for auditing purpose other than -D javax.net 
option.

From: Ragavendhiran Bhiman (rabhiman) 
Date: Thursday, 7 July 2022 at 9:41 PM
To: users@tomcat.apache.org 
Subject: SSL handshake failure logs required for auditing purpose
Hi All,

I require your kind help in logging the SSl connection failure logs including 
iP in the tomcat, Is there any best way to do It without performance impact 
other than -Djava.net debugs in jdk, is there any direct way from tomcat? Or 
any way we can derive any class from JSSE extension classes and add 
HandShakeListener while using the connectors. All our SSL connections are going 
through connectors. So kindly need your help how to log those SSL connection 
auditing logs through best method.
Thanks a lot in advance.

Regards,
Raghav

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Pavan Kumar Tiruvaipati]

Hi,

Java ships cipher suites. We have printed all available cipher suites in
our environment.

Tomcat is not able to enable SSL with JRE 1.8.0_333.

The error says that the client and the server couldn’t find a common cipher
suite.

1. Which cipher suite to be updated in tomcat to enable SSL ?
2. Where do we need to update the cipher suite in tomcat ? server.xml ?

Please advise me if there is any other way to fix the SSL issue. Thank you
in advance.

Regards,
Pavan

On Wed, Jun 15, 2022 at 1:34 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
> Java already ships with a broad variety of cipher suites.
> The crypto providers are listed in the file java.security.
> As long as you don’t modify this file, SSL should work just fine in the
> default java-configuration.
>
> Greetings, Thomas
>
>
> > -Ursprüngliche Nachricht-
> > Von: Pavan Kumar Tiruvaipati 
> > Gesendet: Mittwoch, 15. Juni 2022 09:56
> > An: thomas.hoffm...@speed4trade.com.invalid
> > Cc: Tomcat Users List 
> > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> >
> > Hi,
> >
> > Thanks for the quick response. I will print all the available cipher
> suites.
> >
> > Where do I need to update the cipher to support SSL ?
> >
> >
> > Regards,
> > Pavan
> >
> > On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade GmbH)
> >  wrote:
> >
> > > Hello,
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Pavan Kumar Tiruvaipati 
> > > > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > > > An: Christopher Schultz 
> > > > Cc: Tomcat Users List 
> > > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > > >
> > > > Hi,
> > > >
> > > > Tomcat server started successfully.
> > > >
> > > > I'm seeing the following error in the tomcat logs when SSL is
> > > > enabled in server.xml
> > > >
> > > > Application is not able to run on https://localhost:8080.
> > > >
> > > > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > > > *org.apache.tomcat.util.net.JIoEndpoint
> > > > - Handshake failed*
> > > >
> > > > *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > > > sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > > >
> > > > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > > > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > > >
> > > > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuit
> > > > e(Un
> > > > known
> > > > Source) at
> > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > > > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > > > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > > > Source) at
> > > > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unkno
> > > > wn
> > > > Source) at
> > > > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > > > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > > > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > > > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > > > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
> > > > at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > > org.apache.tomcat.util.net
> > > .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > > > tory.java:233)
> > > > at
> > > > org.apache.tomcat.util.net
> > > .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > > > 01)
> > > > at org.apache.tomcat.util.net
> > > .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > > > at java.lang.Thread.run(Unknown Source)*
> > > >
> > > > If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > > &g

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Pavan Kumar Tiruvaipati]

Hi,

Thanks for the quick response. I will print all the available cipher
suites.

Where do I need to update the cipher to support SSL ?


Regards,
Pavan

On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Pavan Kumar Tiruvaipati 
> > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > An: Christopher Schultz 
> > Cc: Tomcat Users List 
> > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> >
> > Hi,
> >
> > Tomcat server started successfully.
> >
> > I'm seeing the following error in the tomcat logs when SSL is enabled in
> > server.xml
> >
> > Application is not able to run on https://localhost:8080.
> >
> > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > *org.apache.tomcat.util.net.JIoEndpoint
> > - Handshake failed*
> >
> > *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > sun.security.ssl.Alert.createSSLException(Unknown Source) *
> >
> > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> >
> > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Un
> > known
> > Source) at
> > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > Source) at
> > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
> > Source) at
> > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > org.apache.tomcat.util.net
> .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > tory.java:233)
> > at
> > org.apache.tomcat.util.net
> .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > 01)
> > at org.apache.tomcat.util.net
> .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > at java.lang.Thread.run(Unknown Source)*
> >
> > If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > http://localhost:8080).
> >
> > Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
> > required to establish a handshake ?
> >
> > Please let me know if you need more details.
> >
> >
> > Regards,
> > Pavan
> >
> > On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > Pavan,
> > >
> > > Please reply to the list and not me personally.
> > >
> > > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > > >  > > > maxThreads="150" minSpareThreads="25"
> > > maxSpareThreads="75"
> > > > enableLookups="false" disableUploadTimeout="true"
> > > > acceptCount="100"  scheme="https" secure="true"
> > > > connectionTimeout="2"
> > > > clientAuth="false" algorithm="SunX509"
> sslProtocol="TLS"
> > > >keystoreFile="conf/certificate" keystorePass="x"
> > > > useBodyEncodingForURI="true"
> > > >SSLEnabled="true"/>
> > >
> > > That all looks pretty straightforward.
> > >
> > > When you say it's "not working", can you be more specific? Does the
> > > Tomcat server start? Are there any errors or warnings in the logs?
> > >
> > > -chris
> > >
> > > > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > > > mailto:ch...@christopherschultz.net>>
> > > wrote:
> > > >
> > > > Pavan,
> > > &

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Pavan Kumar Tiruvaipati]

Hi,

Tomcat server started successfully.

I'm seeing the following error in the tomcat logs when SSL is enabled in
server.xml

Application is not able to run on https://localhost:8080.

2022-06-15 12:02:43,923 [http-3003-1] DEBUG
*org.apache.tomcat.util.net.JIoEndpoint
- Handshake failed*

*javax.net.ssl.SSLHandshakeException: no cipher suites in common at
sun.security.ssl.Alert.createSSLException(Unknown Source) *

*at sun.security.ssl.Alert.createSSLException(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) *

*at sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Unknown
Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown Source)
at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown Source)
at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
Source) at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.TransportContext.dispatch(Unknown Source) at
sun.security.ssl.SSLTransport.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:233)
at
org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:701)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:503)
at java.lang.Thread.run(Unknown Source)*

If I disable SSL in tomcat server.xml, It's working with Non-SSL (
http://localhost:8080).

Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
required to establish a handshake ?

Please let me know if you need more details.


Regards,
Pavan

On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Pavan,
>
> Please reply to the list and not me personally.
>
> On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> >  > maxThreads="150" minSpareThreads="25"
> maxSpareThreads="75"
> > enableLookups="false" disableUploadTimeout="true"
> > acceptCount="100"  scheme="https" secure="true"
> > connectionTimeout="2"
> > clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
> >keystoreFile="conf/certificate" keystorePass="x"
> > useBodyEncodingForURI="true"
> >SSLEnabled="true"/>
>
> That all looks pretty straightforward.
>
> When you say it's "not working", can you be more specific? Does the
> Tomcat server start? Are there any errors or warnings in the logs?
>
> -chris
>
> > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > mailto:ch...@christopherschultz.net>>
> wrote:
> >
> > Pavan,
> >
> > On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
> >  > We have replaced JDK 1.8 with JRE 1.8.0_333.
> >  >
> >  > SSL configuration was working fine with Tomcat 6.0.45 before
> > replacing JDK
> >  > with JRE.
> >  >
> >  > Now it's not working.
> >  >
> >  > In server.xml, SSL Protocol is set to "TLS".
> >  >
> >  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
> >  >
> >  > Are there any specific protocols / versions to be used to enable
> > SSL ?
> >
> > Please post your  configuration. Remove any secrets that
> may
> > be in there (e.g. passwords).
> >
> > -chris
> >
>

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Christopher Schultz]

Pavan,

Please reply to the list and not me personally.

On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:

                acceptCount="100"  scheme="https" secure="true" 
connectionTimeout="2"

                clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
       keystoreFile="conf/certificate" keystorePass="x" 
useBodyEncodingForURI="true"

       SSLEnabled="true"/>


That all looks pretty straightforward.

When you say it's "not working", can you be more specific? Does the 
Tomcat server start? Are there any errors or warnings in the logs?


-chris

On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Pavan,

On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
 > We have replaced JDK 1.8 with JRE 1.8.0_333.
 >
 > SSL configuration was working fine with Tomcat 6.0.45 before
replacing JDK
 > with JRE.
 >
 > Now it's not working.
 >
 > In server.xml, SSL Protocol is set to "TLS".
 >
 > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
 >
 > Are there any specific protocols / versions to be used to enable
SSL ?

Please post your  configuration. Remove any secrets that may
be in there (e.g. passwords).

-chris



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

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Christopher Schultz]

Pavan,

On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:

We have replaced JDK 1.8 with JRE 1.8.0_333.

SSL configuration was working fine with Tomcat 6.0.45 before replacing JDK
with JRE.

Now it's not working.

In server.xml, SSL Protocol is set to "TLS".

Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?

Are there any specific protocols / versions to be used to enable SSL ?


Please post your  configuration. Remove any secrets that may 
be in there (e.g. passwords).


-chris

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

Re: [External] Re: SSL Handshake Failure - Logging Level

[Mark Thomas]

I've thinking about this further and also noticed this enhancement request:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65401

I think a better solution is to provide a dedicated logger for TLS 
handshake failures and then that logger can be configured to provide the 
desired level of detail without impacting the configuration of any other 
loggers.


Mark


On 06/06/2022 15:50, Amit Pande wrote:

I mean this log is helpful troubleshooting issues in production systems. We 
can't have Tomcat log level set to DEBUG in this case.
And debugging on local/development environments. Agree, in this case, we could 
change the Tomcat logging configuration and get this log.

Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Saturday, June 4, 2022 6:13 AM
To: users@tomcat.apache.org
Subject: Re: [External] Re: SSL Handshake Failure - Logging Level

On 03/06/2022 21:29, Amit Pande wrote:

Thank you, Mark.

I agree changing the log level to error could cause problems you mentioned.
But option like logHandshakeFailuresAtError will be useful to 
troubleshooting/debugging assuming DoS attacks are handled differently.


If the purpose of this is debugging / troubleshooting they why not just enable 
debug logging when needed?

Why does this need to be separately configurable?

Mark




Thinking if this could be a connector level attribute or attribute at SSL host config 
level in "server.xml".

Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Friday, June 3, 2022 12:24 PM
To: users@tomcat.apache.org
Subject: [External] Re: SSL Handshake Failure - Logging Level



On 03/06/2022 15:33, Amit Pande wrote:

Hello,

First, thank you to Mark for adding the access logs in case of SSL handshake failures 
(https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23data=05%7C01%7CAmit.Pande%40veritas.com%7C4a3b22cfe34644c1530508da461b3fe9%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637899380101620149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ZUT9Z1PWQBYpJPWZgAgVX93SJkhDnq%2BQxXJv8BanV9o%3Dreserved=0).
 Really useful enhancement.

On a related note, I am trying to understand if we can log the SSL handshake 
failure at ERROR level instead of current DEBUG level.

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
h
ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat
%
2Futil%2Fnet%2FNio2Endpoint.javadata=05%7C01%7CAmit.Pande%40veri
t
as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318
e
6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
%
7Csdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3Dres
e
rved=0

if (log.isDebugEnabled()) {
   
log.debug(sm.getString("endpoint.err.handshake"), x); }


Are there any issues logging this at error level?


Yes. We generally don't log user triggerable exceptions above debug level as 
that can expose the server to a potential DoS - either by filling the disk with 
log messages or the performance impact of triggering the exceptions.

I guess we could make the log level for that message configurable.
logHandshakeFailuresAtError or something.

Mark

-
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



-
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



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

RE: [External] Re: SSL Handshake Failure - Logging Level

[Amit Pande]

I mean this log is helpful troubleshooting issues in production systems. We 
can't have Tomcat log level set to DEBUG in this case.
And debugging on local/development environments. Agree, in this case, we could 
change the Tomcat logging configuration and get this log.

Thanks,
Amit

-Original Message-
From: Mark Thomas  
Sent: Saturday, June 4, 2022 6:13 AM
To: users@tomcat.apache.org
Subject: Re: [External] Re: SSL Handshake Failure - Logging Level

On 03/06/2022 21:29, Amit Pande wrote:
> Thank you, Mark.
> 
> I agree changing the log level to error could cause problems you mentioned.
> But option like logHandshakeFailuresAtError will be useful to 
> troubleshooting/debugging assuming DoS attacks are handled differently.

If the purpose of this is debugging / troubleshooting they why not just enable 
debug logging when needed?

Why does this need to be separately configurable?

Mark


> 
> Thinking if this could be a connector level attribute or attribute at SSL 
> host config level in "server.xml".
> 
> Thanks,
> Amit
> 
> -Original Message-
> From: Mark Thomas 
> Sent: Friday, June 3, 2022 12:24 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: SSL Handshake Failure - Logging Level
> 
> 
> 
> On 03/06/2022 15:33, Amit Pande wrote:
>> Hello,
>>
>> First, thank you to Mark for adding the access logs in case of SSL handshake 
>> failures 
>> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23data=05%7C01%7CAmit.Pande%40veritas.com%7C4a3b22cfe34644c1530508da461b3fe9%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637899380101620149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ZUT9Z1PWQBYpJPWZgAgVX93SJkhDnq%2BQxXJv8BanV9o%3Dreserved=0).
>>  Really useful enhancement.
>>
>> On a related note, I am trying to understand if we can log the SSL handshake 
>> failure at ERROR level instead of current DEBUG level.
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> h 
>> ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat
>> % 
>> 2Futil%2Fnet%2FNio2Endpoint.javadata=05%7C01%7CAmit.Pande%40veri
>> t 
>> as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318
>> e 
>> 6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>> C 
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>> % 
>> 7Csdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3Dres
>> e
>> rved=0
>>
>> if (log.isDebugEnabled()) {
>>   
>> log.debug(sm.getString("endpoint.err.handshake"), x); }
>>
>> Are there any issues logging this at error level?
> 
> Yes. We generally don't log user triggerable exceptions above debug level as 
> that can expose the server to a potential DoS - either by filling the disk 
> with log messages or the performance impact of triggering the exceptions.
> 
> I guess we could make the log level for that message configurable.
> logHandshakeFailuresAtError or something.
> 
> Mark
> 
> -
> 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
> 

-
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

Re: [External] Re: SSL Handshake Failure - Logging Level

[Mark Thomas]

On 03/06/2022 21:29, Amit Pande wrote:

Thank you, Mark.

I agree changing the log level to error could cause problems you mentioned.
But option like logHandshakeFailuresAtError will be useful to 
troubleshooting/debugging assuming DoS attacks are handled differently.


If the purpose of this is debugging / troubleshooting they why not just 
enable debug logging when needed?


Why does this need to be separately configurable?

Mark




Thinking if this could be a connector level attribute or attribute at SSL host config 
level in "server.xml".

Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Friday, June 3, 2022 12:24 PM
To: users@tomcat.apache.org
Subject: [External] Re: SSL Handshake Failure - Logging Level



On 03/06/2022 15:33, Amit Pande wrote:

Hello,

First, thank you to Mark for adding the access logs in case of SSL handshake failures 
(https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23data=05%7C01%7CAmit.Pande%40veritas.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eVNkn8ZtEi6l1IZ5N8tdmVZ%2B0xj%2FeOFC7G2YdBQxZ0Y%3Dreserved=0).
 Really useful enhancement.

On a related note, I am trying to understand if we can log the SSL handshake 
failure at ERROR level instead of current DEBUG level.

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat%
2Futil%2Fnet%2FNio2Endpoint.javadata=05%7C01%7CAmit.Pande%40verit
as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e
6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7Csdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3Drese
rved=0

if (log.isDebugEnabled()) {
  
log.debug(sm.getString("endpoint.err.handshake"), x); }


Are there any issues logging this at error level?


Yes. We generally don't log user triggerable exceptions above debug level as 
that can expose the server to a potential DoS - either by filling the disk with 
log messages or the performance impact of triggering the exceptions.

I guess we could make the log level for that message configurable.
logHandshakeFailuresAtError or something.

Mark

-
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



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

RE: [External] Re: SSL Handshake Failure - Logging Level

[Amit Pande]

Thank you, Mark.

I agree changing the log level to error could cause problems you mentioned.
But option like logHandshakeFailuresAtError will be useful to 
troubleshooting/debugging assuming DoS attacks are handled differently.

Thinking if this could be a connector level attribute or attribute at SSL host 
config level in "server.xml".

Thanks,
Amit

-Original Message-
From: Mark Thomas  
Sent: Friday, June 3, 2022 12:24 PM
To: users@tomcat.apache.org
Subject: [External] Re: SSL Handshake Failure - Logging Level



On 03/06/2022 15:33, Amit Pande wrote:
> Hello,
> 
> First, thank you to Mark for adding the access logs in case of SSL handshake 
> failures 
> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23data=05%7C01%7CAmit.Pande%40veritas.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eVNkn8ZtEi6l1IZ5N8tdmVZ%2B0xj%2FeOFC7G2YdBQxZ0Y%3Dreserved=0).
>  Really useful enhancement.
> 
> On a related note, I am trying to understand if we can log the SSL handshake 
> failure at ERROR level instead of current DEBUG level.
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat%
> 2Futil%2Fnet%2FNio2Endpoint.javadata=05%7C01%7CAmit.Pande%40verit
> as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e
> 6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7Csdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3Drese
> rved=0
> 
> if (log.isDebugEnabled()) {
>  
> log.debug(sm.getString("endpoint.err.handshake"), x); }
> 
> Are there any issues logging this at error level?

Yes. We generally don't log user triggerable exceptions above debug level as 
that can expose the server to a potential DoS - either by filling the disk with 
log messages or the performance impact of triggering the exceptions.

I guess we could make the log level for that message configurable. 
logHandshakeFailuresAtError or something.

Mark

-
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

Re: SSL Handshake Failure - Logging Level

[Mark Thomas]

On 03/06/2022 15:33, Amit Pande wrote:

Hello,

First, thank you to Mark for adding the access logs in case of SSL handshake 
failures 
(https://github.com/apache/tomcat/commit/acf6076d7118571ebc881984b96792f861b72bb2#).
 Really useful enhancement.

On a related note, I am trying to understand if we can log the SSL handshake 
failure at ERROR level instead of current DEBUG level.

https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/Nio2Endpoint.java

if (log.isDebugEnabled()) {
 log.debug(sm.getString("endpoint.err.handshake"), x);
}

Are there any issues logging this at error level?


Yes. We generally don't log user triggerable exceptions above debug 
level as that can expose the server to a potential DoS - either by 
filling the disk with log messages or the performance impact of 
triggering the exceptions.


I guess we could make the log level for that message configurable. 
logHandshakeFailuresAtError or something.


Mark

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

Re: SSL trouble in embeddedLand

[Rob Sargent]

On 1/22/21 3:06 PM, Christopher Schultz wrote:


You are telling keytool to read-in localhost-rsa-key.pem as a PKCS12 
file, which is most likely wrong. You don't want to import a keystore, 
you want to import a key. Unfortunately, keytool doesn't allow that. 
But openssl does:


$ openssl pkcs12 -export -in localhost-rsa.crt -inkey 
localhost-rsa-key.pem -certfile CA-intermediate.crt -out localhost.p12 
-chain


Now you can import that keystore into your cacerts file:

$ keytool -importkeystore -srckeystore localhost.p12
 -srcstoretype pkcs12 -destkeystore /tmp/key/cacerts.pkcs12
 -deststoretype pkcs12 -srcalias tomcat -destalias tomcat


I presumed I was messing something up.
PEM files aren't keystores, so keytool can do almost nothing with 
them. You cam import a PEM certificate, but not its key (directly).


Why are you copying everything from the JVM's cacerts file into your 
keystore? Maybe I'm confused about what you are trying to do.


First for practice/sandbox.  Then if it worked I could do the same to 
actual cacerts and have the JVM find it without further ado.


I will take the remainder of your message under strong advisement.
Thank you, very very much.
 (I'm not sure, but I think I can get away with a self-sign cert.)

Re: SSL trouble in embeddedLand

[Christopher Schultz]

Rob,

On 1/22/21 15:21, Rob Sargent wrote:


For completeness, I must admit that I was unable to use PKCS12 files.  I 
had to use JKS format.


I copied and transformed my cacerts files as per keytool recommendation:

    keytool -importkeystore -srckeystore
    /usr/lib/jvm/java-15-oracle/lib/security/cacerts -destkeystore
    /tmp/key/cacerts.pkcs12 -deststoretype pkcs12

Then add tomcat's localhost key

    keytool -importkeystore -srckeystore localhost-rsa-key.pem
    -srcstoretype pkcs12 -destkeystore /tmp/key/cacerts.pkcs12
    -deststoretype pkcs12 -srcalias tomcat -destalias tomcat
    keytool error: java.io.IOException: toDerInputStream rejects tag 
type 45


You are telling keytool to read-in localhost-rsa-key.pem as a PKCS12 
file, which is most likely wrong. You don't want to import a keystore, 
you want to import a key. Unfortunately, keytool doesn't allow that. But 
openssl does:


$ openssl pkcs12 -export -in localhost-rsa.crt -inkey 
localhost-rsa-key.pem -certfile CA-intermediate.crt -out localhost.p12 
-chain


Now you can import that keystore into your cacerts file:

$ keytool -importkeystore -srckeystore localhost.p12
 -srcstoretype pkcs12 -destkeystore /tmp/key/cacerts.pkcs12
 -deststoretype pkcs12 -srcalias tomcat -destalias tomcat


Try to get the alias from the .pems

    keytool -list -keystore localhost-rsa-cert.pem -storetype pkcs12
    keytool error: java.io.IOException: toDerInputStream rejects tag 
type 67

    keytool -list -keystore localhost-rsa-key.pem -storetype pkcs12
    keytool error: java.io.IOException: toDerInputStream rejects tag 
type 45


I'm certainly doing something wrong, but I'm sticking with JKS for now.


PEM files aren't keystores, so keytool can do almost nothing with them. 
You cam import a PEM certificate, but not its key (directly).


Why are you copying everything from the JVM's cacerts file into your 
keystore? Maybe I'm confused about what you are trying to do.


Most people just want to mint a key+cert and have Tomcat use that for 
TLS. You can do that very simply:


$ keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 4096 -alias 
${HOSTNAME} -keystore ${HOSTNAME}.p12 -storetype PKCS12 -ext 
san=dns:${HOSTNAME}


Fill-out all the stuff. This gives you a new RSA key and a self-signed 
certificate. If self-signed is okay with you, you are done.


If you want to have that signed by a CA, then you:

$ keytool -certreq -alias ${HOSTNAME} -file ${HOSTNAME}.csr -keystore 
${HOSTNAME}.p12 -storetype PKCS12


Now you have a CSR in ${HOSTNAME}.csr. Send it to your CA For signature. 
Now import their signed cert into your keystore:


(CA's root first, if necessary)
$ keytool -import -alias [Authority.CA] -trustcacerts -file [authority's 
CA cert] -keystore ${HOSTNAME}.jks


(CA's intermediate, if necessary)
$ keytool -import -alias [Authority.intermediate] -trustcacerts -file 
[authority's intermediate cert] -keystore ${HOSTNAME}.jks


(Finally, your server's newly-signed cert)
$ keytool -import -alias ${HOSTNAME} -file ${HOSTNAME}.crt -keystore 
${HOSTNAME}.jks


Configure localhost.p12 as your keystore in  and you should 
be done.


There is no need to merge-in the JVM's trust store into your server's 
key store.


Even better, if you like working with PEM files better (I do!), you 
don't every have to run keytool or use a PKCS12 or JKS file. Just use 
the PEM file in:


 

Hope that helps,
-chris

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

Re: SSL trouble in embeddedLand

[Rob Sargent]

For completeness, I must admit that I was unable to use PKCS12 files.  I 
had to use JKS format.


I copied and transformed my cacerts files as per keytool recommendation:

   keytool -importkeystore -srckeystore
   /usr/lib/jvm/java-15-oracle/lib/security/cacerts -destkeystore
   /tmp/key/cacerts.pkcs12 -deststoretype pkcs12

Then add tomcat's localhost key

   keytool -importkeystore -srckeystore localhost-rsa-key.pem 
   -srcstoretype pkcs12 -destkeystore /tmp/key/cacerts.pkcs12
   -deststoretype pkcs12 -srcalias tomcat -destalias tomcat
   keytool error: java.io.IOException: toDerInputStream rejects tag type 45

Try to get the alias from the .pems

   keytool -list -keystore localhost-rsa-cert.pem -storetype pkcs12
   keytool error: java.io.IOException: toDerInputStream rejects tag type 67
   keytool -list -keystore localhost-rsa-key.pem -storetype pkcs12
   keytool error: java.io.IOException: toDerInputStream rejects tag type 45

I'm certainly doing something wrong, but I'm sticking with JKS for now.

Re: SSL trouble in embeddedLand

[Rob Sargent]

On 1/20/21 8:15 AM, Rémy Maucherat wrote:

On Tue, Jan 19, 2021 at 5:02 AM Rob Sargent  wrote:

Dealing with a complex configuration using the embedded API can be a bit
problematic. If you're using a recent Tomcat 9 (9.0.38+), you could use the
code generator that was designed for ahead of time compilation to help you
out: it will produce Tomcat embedded equivalent code to the server.xml
you're using. I would think server.xml is easier to get right, and there
are probably tons of examples that you can use to help out. Then you can
cut and paste the generated code and refine it as needed.

If you want to try it out, you can add "-generateCode" to the Tomcat
command line, such as "./bin/catalina.sh run -generateCode". The code will
be generated in the work directory.

Of course, that won't help you get the certificates right. Good luck !

Rémy
That's an interesting tack but I haven't "installed" Apache, there is no 
catalina.sh and no server.xml.
My intent was to avoid the addition of the entire customary web site 
infrastructure when all I really wanted was the correct handling of a 
Selector (and https communication on same).  And now, thanks to Mark's 
suggestion about Tomcat's own test keys I have reached my goal, at least 
in a dev environment.

Now on to scaling and AWS deployment.  Wish me luck.

Re: SSL trouble in embeddedLand

[Rémy Maucherat]

On Tue, Jan 19, 2021 at 5:02 AM Rob Sargent  wrote:

>
> Stuck in my basement with no real domain I'm having trouble setting up
> SSL/TLS on an embedded tomcat instance. And I'm very lost, having tried
> more dead ends than I can remember.
>
> I used this to generate cert and key
> openssl req -out localhost.crt -key localhost.key \
> -newkey rsa:2048 -nodes -sha256 \
> -subj '/CN=localhost' -extensions EXT -config <( \
> printf "[dn]\nCN=localhost\n[req]\ndistinguished_name =
> dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature,
> nonRepudiation, keyEncipherment,
> dataEncipherment\nextendedKeyUsage=serverAuth")
>
> and try to apply those with
>
> -Djavax.net.ssl.trustStore=/tmp/key/localhost.crt
> -Djavax.net.ssl.trustStorePassword=changeit
> -Djavax.net.ssl.trustStoreType=PKCS12
> -Djavax.net.ssl.keyStore=/tmp/key/localhost.key
> -Djavax.net.ssl.keyStorePassword=changeit
> -Dhttps.protocols=TLSv1.2,TLSv1.3
> -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3
>
> I get "toDerInputStream rejects tag type 45".
>
> That error rears its ugly head in several places such when adding those
> same two localhost files to a pkcs12 rendition of the OS's cacerts file
> using below. The crt goes in quietly. (I'm couldn't convince my self of
> the openssl equivalent of this command)
> root@gitanmax:/tmp/key# keytool -importkeystore -srckeystore
> localhost.key -srckeypass changeit -srcstoretype pkcs12 -destkeystore
> cacerts.pkcs12 -deststoretype pkcs12 -srcalias localhost -destalias
> tomcatlocal
> Importing keystore localhost.key to cacerts.pkcs12...
> Enter destination keystore password: changeit
> Enter source keystore password: changeit
> keytool error: java.io.IOException: toDerInputStream rejects tag type 45
>
> My actual first attempt was to just use keytool to generate a cert
> interactively, filling in my own bogus values but that hit the domain
> name mismatch gotcha.
>
> Then, there's confusion on the java side as well.
>
> My plan was to add a connector for my webapp
>
> embeddedTomcat = new Tomcat();
> logger.debug("handing in CATALINA_HOME as " +
> System.getenv("CATALINA_HOME"));
> embeddedTomcat.setPort(tomcatPort-1);
> embeddedTomcat.enableNaming();
> Connector defaultConnector = embeddedTomcat.getConnector(); // an init,
> really
> defaultConnector.setSecure(true); // force https?
>
> Service service = embeddedTomcat.getService();
> service.addConnector(addTLSConnector(tomcatPort));
>
> logger.info("tomcatd listening on port " + tomcatPort);
> String contextRootPath = System.getenv("CATALINA_HOME");
> logger.debug("contextRootPath is {}", contextRootPath);
> Context contextTomcat = embeddedTomcat.addContext("", new
> File(contextRootPath + "/sgs").getAbsolutePath());
> logger.debug("host: {}, general context basename {}",
> embeddedTomcat.getHost(), contextTomcat.getBaseName());
> //TODO: cut from here ...
> java.time.LocalDateTime bootDT = java.time.LocalDateTime.now();
> Tomcat.addServlet(contextTomcat, "monitor", new HttpServlet() {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> ServletOutputStream out = resp.getOutputStream();
> out.write("SGS Agent monitor: SGS_OK\n".getBytes());
> out.write(("Up since " + bootDT.toString()).getBytes());
> out.write(("\nTime now " +
> java.time.LocalDateTime.now().toString()).getBytes());
> out.flush();
> out.close();
> }
> });
> contextTomcat.addServletMappingDecoded("/monitor", "monitor");
> // My webapp
> Context sgsContext = embeddedTomcat.addWebapp("/sgs", contextRootPath +
> "/sgs"); // /sgs.war
> embeddedTomcat.start();
> embeddedTomcat.getServer().await();
>
> private Connector addTLSConnector(Connector connector, int tcport) {
> File keyFile = new File (System.getProperty("SGSSRVR_keystoreFile"));
> if (! keyFile.exists()) throw new RuntimeException("where's the
> keystore?");
> connector.setPort(tcport);
> connector.setSecure(true);
> connector.setScheme("https");
> connector.setProperty("protocol", "HTTP/1.1");
> connector.setProperty("sslProtocol", "TLS");
> connector.setProperty("address","127.0.0.1");
> connector.setProperty("clientAuth", "false");
> connector.setProperty("maxThreads", "200");
> connector.setProperty("protocol",
> "org.apache.coyote.http11.Http11NioProtocol");
> connector.setProperty("SSLEnabled", "true");
> return connector;
> }
>
> private Connector addTLSConnector(int tcport) {
> Connector connector = new Connector();
> addTLSConnector(connector, tcport);
> return connector;
> }
>
> That "monitor" works, on a separate port, on either http or https as per
> defaultConnector.setSecure(isHttps);
> but possibly because I've diddle with chrome's security settings.
>
> I have a similar "monitor" as a servlet which I use as my
> is-anybody-home call to start my analyses. And of course can also use
> it via the browser at /seg/webmonitor.
>
> All these behave when SSL is not in play, but I'm forced, very much
> against my will, to use SSL so here 

Re: SSL trouble in embeddedLand

[Rob Sargent]

My recommendation would be:
- start with the test certs from the Tomcat unit tests as they are known
   to work
- get your code working so you know the code is good
- they try with your own keys certificates

Mark


That's exactly what I'll do next.  Thank you very much.
rjs

Re: SSL trouble in embeddedLand

[Mark Thomas]

On 19/01/2021 04:02, Rob Sargent wrote:
> 
> Stuck in my basement with no real domain I'm having trouble setting up
> SSL/TLS on an embedded tomcat instance. And I'm very lost, having tried
> more dead ends than I can remember.
> 
> I used this to generate cert and key
> openssl req -out localhost.crt -key localhost.key \
> -newkey rsa:2048 -nodes -sha256 \
> -subj '/CN=localhost' -extensions EXT -config <( \
> printf "[dn]\nCN=localhost\n[req]\ndistinguished_name =
> dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature,
> nonRepudiation, keyEncipherment,
> dataEncipherment\nextendedKeyUsage=serverAuth")

That isn't a certificate and key. It is a certificate signing request
(csr) and a key.

You might want to take a look at:
http://tomcat.apache.org/presentations.html

search for "TLS key/certificate generation". That creates a private CA
and then uses it to issue a cert for localhost. Having a private CA lets
you test stuff things client certificate authentication.

Note that this dates from before the subjectAltName requirements so it
will need some tweaks (-ext san=dns:localhost)

Alternatively, grab the (and I can't emphasis this enough) *TEST* keys
and certs from the Tomcat unit tests and use those:

https://github.com/apache/tomcat/tree/master/test/org/apache/tomcat/util/net

> and try to apply those with
> 
> -Djavax.net.ssl.trustStore=/tmp/key/localhost.crt
> -Djavax.net.ssl.trustStorePassword=changeit
> -Djavax.net.ssl.trustStoreType=PKCS12
> -Djavax.net.ssl.keyStore=/tmp/key/localhost.key
> -Djavax.net.ssl.keyStorePassword=changeit
> -Dhttps.protocols=TLSv1.2,TLSv1.3
> -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3

As a general rule it is always better to configure a Tomcat connector
explicitly rather than relay on the fallback to the system properties.

> I get "toDerInputStream rejects tag type 45".
> 
> That error rears its ugly head in several places such when adding those
> same two localhost files to a pkcs12 rendition of the OS's cacerts file
> using below. The crt goes in quietly. (I'm couldn't convince my self of
> the openssl equivalent of this command)
> root@gitanmax:/tmp/key# keytool -importkeystore -srckeystore
> localhost.key -srckeypass changeit -srcstoretype pkcs12 -destkeystore
> cacerts.pkcs12 -deststoretype pkcs12 -srcalias localhost -destalias
> tomcatlocal
> Importing keystore localhost.key to cacerts.pkcs12...
> Enter destination keystore password: changeit
> Enter source keystore password: changeit
> keytool error: java.io.IOException: toDerInputStream rejects tag type 45
> 
> My actual first attempt was to just use keytool to generate a cert
> interactively, filling in my own bogus values but that hit the domain
> name mismatch gotcha.

"-ext san=dns:localhost" should help

> Then, there's confusion on the java side as well.
> 
> My plan was to add a connector for my webapp
> 
> embeddedTomcat = new Tomcat();
> logger.debug("handing in CATALINA_HOME as " +
> System.getenv("CATALINA_HOME"));
> embeddedTomcat.setPort(tomcatPort-1);
> embeddedTomcat.enableNaming();
> Connector defaultConnector = embeddedTomcat.getConnector(); // an init,
> really
> defaultConnector.setSecure(true); // force https?

Nope. That simply tells Tomcat to treat connections as secure. You don't
want that except in some proxy scenarios.

> Service service = embeddedTomcat.getService();
> service.addConnector(addTLSConnector(tomcatPort));
> 
> logger.info("tomcatd listening on port " + tomcatPort);
> String contextRootPath = System.getenv("CATALINA_HOME");
> logger.debug("contextRootPath is {}", contextRootPath);
> Context contextTomcat = embeddedTomcat.addContext("", new
> File(contextRootPath + "/sgs").getAbsolutePath());
> logger.debug("host: {}, general context basename {}",
> embeddedTomcat.getHost(), contextTomcat.getBaseName());
> //TODO: cut from here ...
> java.time.LocalDateTime bootDT = java.time.LocalDateTime.now();
> Tomcat.addServlet(contextTomcat, "monitor", new HttpServlet() {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> ServletOutputStream out = resp.getOutputStream();
> out.write("SGS Agent monitor: SGS_OK\n".getBytes());
> out.write(("Up since " + bootDT.toString()).getBytes());
> out.write(("\nTime now " +
> java.time.LocalDateTime.now().toString()).getBytes());
> out.flush();
> out.close();
> }
> });
> contextTomcat.addServletMappingDecoded("/monitor", "monitor");
> // My webapp
> Context sgsContext = embeddedTomcat.addWebapp("/sgs", contextRootPath +
> "/sgs"); // /sgs.war
> embeddedTomcat.start();
> embeddedTomcat.getServer().await();
> 
> private Connector addTLSConnector(Connector connector, int tcport) {
> File keyFile = new File (System.getProperty("SGSSRVR_keystoreFile"));
> if (! keyFile.exists()) throw new RuntimeException("where's the
> keystore?");
> connector.setPort(tcport);
> connector.setSecure(true);
> connector.setScheme("https");
> connector.setProperty("protocol", 

Re: SSL certificate makes site dont work

[Christopher Schultz]

Carles,

On 9/22/20 08:57, Carles Franquesa wrote:
> Trying to install an SSL certificate on 8.5.57.
> 
> Once created the cert files, and with a jks available, and set in a
> connector into server.xml file, cannot connect to the page.
> 
> The connectors code is
> 
> '''
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> clientAuth="false"
> sslProtocol="TLS"
> keystoreFile="/opt/tomcat/certificat/app.aprenonline.eu.jks"
> keystoreType="JKS" keystorePass="***"/>
> 
> 
> 
> '''
> 
> When trying to connect from the browser, the status bar says "trying to
> make a secure connection..." but it hangs at this pont.

What URL is showing in the browser?

Are there any errors or warnings during startup in the log files?

-chris

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

Re: SSL debug?

[James H. H. Lampert]

On 9/8/20 1:12 PM, john.e.gr...@wellsfargo.com.INVALID wrote:

I don't remember the precise problem, but verbose SSL will tell you
what trust store and key store you're using, among other things.


I don't blame you. It's been close to a month since I last attempted to 
do something about this.


The problem is that when the webapp tries to call the Google
  https://maps.googleapis.com/maps/api/geocode
web service, it gets:

Unable to find acceptable protocols. isFallback=false,
modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1,
TLS_1_0], supportsTlsExtensions=true),
ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0],
supportsTlsExtensions=true), ConnectionSpec()], supported
protocols=[TLSv1]


In the past, removing DESede from the list of disabled algorithms solved 
the problem, but it appears that in the latest IBM Java 8 JVMs, DESede 
was not only disabled, but *removed* from the JVM.


--
JHHL


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

RE: SSL debug?

[John.E.Gregg]

James,

> -Original Message-
> From: James H. H. Lampert 
> Sent: Tuesday, September 08, 2020 2:13 PM
> To: Tomcat Users List 
> Subject: Re: SSL debug?
> 
> I'm finally back on this problem.
> 
> >> We are once again having SSL difficulties with our webapp connecting
> >> with an outside web service: the java.security override that had
> >> solved the problem in the past (specifically, removing "DESede" from
> >> the "jdk.tls.disabledAlgorithms" in an override file) is now failing
> >> with certain Java 8 JVMs on AS/400s.
> 
> More specifically, the call is to
>  https://maps.googleapis.com/maps/api/geocode
> 
> Last month, I got a suggestion (on the Midrange Java List, but endorsed
> when I asked about it here) of adding "-Djavax.net.debug=ssl:handshake"
> to catalina.sh.
> 
> Today, I finally tried it. It took several tries before I got anything at 
> all, but
> when I did, I got 678k of information. Any suggestions on where my
> proverbial needle would be in that haystack, and what it would look like?
> 
> Also today, I tried the "sledgehammer" approach of editing the JVM's own
> java.security instead of merely overriding it. No difference.
> 
> --
> JHHL
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

I don't remember the precise problem, but verbose SSL will tell you what trust 
store and key store you're using, among other things.  You'll see something 
like this:

keyStore is: /path/to/keystore
...
trustStore is: /path/to/truststore
...

Are those the right files?

After the trustStore path, you should then see a list of all the CAs in the 
trust store.

Ideally, you'd do this on a quiet system.  As you've seen, it produces a ton of 
output and there is no way to distinguish messages from one thread vs another.

Re: SSL debug?

[James H. H. Lampert]

I'm finally back on this problem.


We are once again having SSL difficulties with our webapp connecting
with an outside web service: the java.security override that had solved
the problem in the past (specifically, removing "DESede" from the
"jdk.tls.disabledAlgorithms" in an override file) is now failing with
certain Java 8 JVMs on AS/400s.


More specifically, the call is to
https://maps.googleapis.com/maps/api/geocode

Last month, I got a suggestion (on the Midrange Java List, but endorsed 
when I asked about it here) of adding "-Djavax.net.debug=ssl:handshake" 
to catalina.sh.


Today, I finally tried it. It took several tries before I got anything 
at all, but when I did, I got 678k of information. Any suggestions on 
where my proverbial needle would be in that haystack, and what it would 
look like?


Also today, I tried the "sledgehammer" approach of editing the JVM's own 
java.security instead of merely overriding it. No difference.


--
JHHL

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

Re: SSL debug?

[Mark Thomas]

On 12/08/2020 16:29, James H. H. Lampert wrote:
> Question:
> 
> We are once again having SSL difficulties with our webapp connecting
> with an outside web service: the java.security override that had solved
> the problem in the past (specifically, removing "DESede" from the
> "jdk.tls.disabledAlgorithms" in an override file) is now failing with
> certain Java 8 JVMs on AS/400s.
> 
> Somebody on the Midrange Java List suggested using
> 
>> -Djavax.net.debug=ssl:handshake
> 
> in catalina.sh, to gather more information on the problem.
> 
> Would that actually help with our present situation? Or would it only
> cover problems with users connecting to Tomcat from their browsers?

That should show TLS handshakes from both user agent to Tomcat and
application to external service.

Mark

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

Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[Mark Thomas]

On 19/07/2020 13:55, Christopher Schultz wrote:
> Mark,
> 
> On 7/18/20 10:01, Mark Thomas wrote:
>> On 17/07/2020 21:47, James H. H. Lampert wrote:
>>> Running two connectors seems to work just fine, but I'm having
>>> trouble getting one of them to only take TLS 1.2
>>>
>>> In reply to my query:
>>>
> Given all this, is it possible to (1) have Tomcat listen on
> two separate HTTPS ports, and (2) have one of the ports
> require TLS 1.2, but the other accept something our AS/400
> can use?
>>>
>>> On 7/17/20 10:03 AM, Mark Thomas wrote:
>>>
 Yes. You need two Connector elements specifying different ports
 and different protocols. They should be able to use the same
 certificate configuration.
>>>
>>> I just ran a test on our development Amazon EC2 instance, and
>>> verified that I could listen on two different ports (existing
>>> 8443 and now 7443), and I limited (or so I thought) 8443 (to
>>> which I have 443 rerouted through iptables) to TLS 1.2.
>>>
>>> Except that SSLLabs tells me it's still accepting TLS 1.0 and
>>> 1.1!
>>>
>>> I commented out the connector for 8443 and restarted Tomcat, but
>>> it's still giving the same report from SSLLabs.
>>>
>>> The connector for 8443 in server.xml looks like this (lines
>>> truncated):
 >>> protocol="org.apache.coyote.http1$ compression="on"
 compressionMinSize="2048" noCompressionUserAgents="goz$
 maxThreads="1000" socket.appReadBufSize="1024" socket.app$
 keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias=$
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256$
 clientAuth="false" sslProtocol="TLSv1.2" />
>>>
>>> The 'sslProtocol="TLSv1.2"' clause is copied directly from the
>>> Tomcat 7 installation on our most security-conscious customer's
>>> AS/400; this Tomcat is 8.5. Am I specifying it wrong?
> 
>> I should probably remind myself why this is the way this is.
> 
>> You want:
> 
>> sslProtocol="TLS" sslEnabledProtocols="TLSv1.2"
> 
>> And to answer my question above, because that is the way the JSSE
>> API has been written.
> 
> We should probably just merge these into a single attribute and "do
> the right thing":
> 
> 1. If not specified, do nothing unusual
> 2. If the value includes a ",", use it for sslEnabledProtocols, use
> "TLS" as sslProtocol
> 3. Otherwise, use value for both sslProtocol AND sslEnabledProtocols

Seems reasonable.

> Practically speaking, the only useful value for sslProtocol today is
> "TLS". You can specify e.g. "TLSv1.2" and I think it will restrict
> sslEnabledProtocols to TLSv1.2 but using the same value for both has
> the same effect, of course.
> 
> In the future, if anything other than "TLS" makes sense for
> sslProtocol, we can change Tomcat to support that.
> 
> We should also probably have SSLEnabled="true" be the default if any
> TLS-related configuration option is used on a connector.

That might catch a few folks by surprise but it does seem reasonable.

I think there is scope in Tomcat 10 to clean up the TLS configuration a
little more. We have a couple of months until Jakarta EE 9 is released
so there is time to improve this.

Mark

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

Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[James H. H. Lampert]

Mark Thomas and Christopher Schultz wrote:


You want:

sslProtocol="TLS" sslEnabledProtocols="TLSv1.2"

And to answer my question above, because that is the way the JSSE
API has been written.


We should probably just merge these into a single attribute and "do
the right thing":

1. If not specified, do nothing unusual
2. If the value includes a ",", use it for sslEnabledProtocols, use
"TLS" as sslProtocol
3. Otherwise, use value for both sslProtocol AND sslEnabledProtocols

Practically speaking, the only useful value for sslProtocol today is
"TLS". You can specify e.g. "TLSv1.2" and I think it will restrict
sslEnabledProtocols to TLSv1.2 but using the same value for both has
the same effect, of course.

In the future, if anything other than "TLS" makes sense for
sslProtocol, we can change Tomcat to support that.

We should also probably have SSLEnabled="true" be the default if any
TLS-related configuration option is used on a connector.

WDYT?


Well, I think (from direct experience) that for Tomcat 7 running on an 
AS/400, "merge these into a single attribute and 'do the right thing'" 
*is* how it works, so the entirety of Christopher's suggestion makes 
perfect sense to me.


At any rate, thanks to both of you; it works.

Although it does raise the question of whether the observed behavior in 
Tomcat 7 on an AS/400 is a Tomcat 7 thing or an AS/400 thing.


--
JHHL

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

Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 7/18/20 10:01, Mark Thomas wrote:
> On 17/07/2020 21:47, James H. H. Lampert wrote:
>> Running two connectors seems to work just fine, but I'm having
>> trouble getting one of them to only take TLS 1.2
>>
>> In reply to my query:
>>
 Given all this, is it possible to (1) have Tomcat listen on
 two separate HTTPS ports, and (2) have one of the ports
 require TLS 1.2, but the other accept something our AS/400
 can use?
>>
>> On 7/17/20 10:03 AM, Mark Thomas wrote:
>>
>>> Yes. You need two Connector elements specifying different ports
>>> and different protocols. They should be able to use the same
>>> certificate configuration.
>>
>> I just ran a test on our development Amazon EC2 instance, and
>> verified that I could listen on two different ports (existing
>> 8443 and now 7443), and I limited (or so I thought) 8443 (to
>> which I have 443 rerouted through iptables) to TLS 1.2.
>>
>> Except that SSLLabs tells me it's still accepting TLS 1.0 and
>> 1.1!
>>
>> I commented out the connector for 8443 and restarted Tomcat, but
>> it's still giving the same report from SSLLabs.
>>
>> The connector for 8443 in server.xml looks like this (lines
>> truncated):
>>> >> protocol="org.apache.coyote.http1$ compression="on"
>>> compressionMinSize="2048" noCompressionUserAgents="goz$
>>> maxThreads="1000" socket.appReadBufSize="1024" socket.app$
>>> keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias=$
>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256$
>>> clientAuth="false" sslProtocol="TLSv1.2" />
>>
>> The 'sslProtocol="TLSv1.2"' clause is copied directly from the
>> Tomcat 7 installation on our most security-conscious customer's
>> AS/400; this Tomcat is 8.5. Am I specifying it wrong?
>
> I should probably remind myself why this is the way this is.
>
> You want:
>
> sslProtocol="TLS" sslEnabledProtocols="TLSv1.2"
>
> And to answer my question above, because that is the way the JSSE
> API has been written.

We should probably just merge these into a single attribute and "do
the right thing":

1. If not specified, do nothing unusual
2. If the value includes a ",", use it for sslEnabledProtocols, use
"TLS" as sslProtocol
3. Otherwise, use value for both sslProtocol AND sslEnabledProtocols

Practically speaking, the only useful value for sslProtocol today is
"TLS". You can specify e.g. "TLSv1.2" and I think it will restrict
sslEnabledProtocols to TLSv1.2 but using the same value for both has
the same effect, of course.

In the future, if anything other than "TLS" makes sense for
sslProtocol, we can change Tomcat to support that.

We should also probably have SSLEnabled="true" be the default if any
TLS-related configuration option is used on a connector.

WDYT?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8UQsgACgkQHPApP6U8
pFhGag/+IjZWCK1XSHsUr51tmTAz9JmK2eIabQsf7fIM3pmjXBCKJqYcsEd6tR//
cDAgV/mjA6BRXVpl3D4kCsmp8w8yCghirWXYRj4Qs6aKp3a6KgRsQyB7eDnClfQ0
0ic5pjsd699t1vcBxvwC59drs8HCnzDoEfJu91RyYcMl1s/2UiVG8Fg0k4ztw+GQ
abhgdmJILtIe0H8q8t5tOverjAnUXJhfoc0Nxd1FaLFRNHQKS80O9vlXODzz0ngE
wDDppmbEI5fcnK1YTp/qJYEQ2Bdn3zvOywWvLeZQYmBEuh0x4wLOQsjFJgwt45uT
3ocIuHAtbqWQOXZ//WzPof91CAIMOPV8nZdBtH5op5RJJpu5dPvnKS73MD/8WZWJ
v+YBl9AIrrW/2r+U+h8XfrFpsUNGFwG4pNTE4CtkUdoR+hkcgcX2vSI8zG0OyTuu
cwoMcVQsMQPhnMNLIpR/Y+lBce8hf2U8m6Bs5To8EWTclzlY7UuU75vC6SUdP3fv
2ULHtivG9xOiSEX635eiVpQ2U/1vQjH5KugpsdJ1AoiaDUFF+qDFa5fSiqYeBw8z
PCuDCyJW89BzCjnbzQH6PKuXE4iRPudsJJ+5fplWwKai3vboR3JX5vUlzczuUfqg
FpaOHtHEQ08N7y2NB9KzFe0AdbH8iJ9CY1gwahXgDQ9bQgO9nsY=
=qmvC
-END PGP SIGNATURE-

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

Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[Mark Thomas]

On 17/07/2020 21:47, James H. H. Lampert wrote:
> Running two connectors seems to work just fine, but I'm having trouble
> getting one of them to only take TLS 1.2
> 
> In reply to my query:
> 
>>> Given all this, is it possible to (1) have Tomcat listen on two separate
>>> HTTPS ports, and (2) have one of the ports require TLS 1.2, but the
>>> other accept something our AS/400 can use?
> 
> On 7/17/20 10:03 AM, Mark Thomas wrote:
> 
>> Yes. You need two Connector elements specifying different ports and
>> different protocols. They should be able to use the same certificate
>> configuration.
> 
> I just ran a test on our development Amazon EC2 instance, and verified
> that I could listen on two different ports (existing 8443 and now 7443),
> and I limited (or so I thought) 8443 (to which I have 443 rerouted
> through iptables) to TLS 1.2.
> 
> Except that SSLLabs tells me it's still accepting TLS 1.0 and 1.1!
> 
> I commented out the connector for 8443 and restarted Tomcat, but it's
> still giving the same report from SSLLabs.
> 
> The connector for 8443 in server.xml looks like this (lines truncated):
>> >    keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias=$
>>    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256$
>>    clientAuth="false" sslProtocol="TLSv1.2" />
> 
> The 'sslProtocol="TLSv1.2"' clause is copied directly from the Tomcat 7
> installation on our most security-conscious customer's AS/400; this
> Tomcat is 8.5. Am I specifying it wrong?

I should probably remind myself why this is the way this is.

You want:

sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2"

And to answer my question above, because that is the way the JSSE API
has been written.

Mark

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

Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[James H. H. Lampert]

On 7/17/20 2:36 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:

This looks like a cipher, not an alias

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256


As I said, of course it's a cipher. I said up front that the lines were 
truncated, in order to fit in an email.


I can't imagine why seeing the whole connector would make a difference, 
but if anybody wants to see it un-truncated, (albeit with the same 
redactions), it's now also on ServerFault, at

  https://serverfault.com/q/1025706/498231?sem=2

--
JHHL

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

Re: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[James H. H. Lampert]

On 7/17/20 2:36 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:

This looks like a cipher, not an alias

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256


It is. The lines are truncated at 72 characters for the email.

--
JHHL

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

RE: Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[jonmcalexander]

This looks like a cipher, not an alias

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: James H. H. Lampert  
Sent: Friday, July 17, 2020 3:47 PM
To: Tomcat Users List 
Subject: Problem with protocols, Re: SSL/TLS issue: can we listen on more than 
one secured port, with different protocols enabled?

Running two connectors seems to work just fine, but I'm having trouble getting 
one of them to only take TLS 1.2

In reply to my query:

>> Given all this, is it possible to (1) have Tomcat listen on two 
>> separate HTTPS ports, and (2) have one of the ports require TLS 1.2, 
>> but the other accept something our AS/400 can use?

On 7/17/20 10:03 AM, Mark Thomas wrote:

> Yes. You need two Connector elements specifying different ports and 
> different protocols. They should be able to use the same certificate 
> configuration.

I just ran a test on our development Amazon EC2 instance, and verified that I 
could listen on two different ports (existing 8443 and now 7443), and I limited 
(or so I thought) 8443 (to which I have 443 rerouted through iptables) to TLS 
1.2.

Except that SSLLabs tells me it's still accepting TLS 1.0 and 1.1!

I commented out the connector for 8443 and restarted Tomcat, but it's still 
giving the same report from SSLLabs.

The connector for 8443 in server.xml looks like this (lines truncated):
>  protocol="org.apache.coyote.http1$
>  compression="on" compressionMinSize="2048" noCompressionUserAgents="goz$
>maxThreads="1000" socket.appReadBufSize="1024" socket.app$
>keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias=$
>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256$
>clientAuth="false" sslProtocol="TLSv1.2" />

The 'sslProtocol="TLSv1.2"' clause is copied directly from the Tomcat 7 
installation on our most security-conscious customer's AS/400; this Tomcat is 
8.5. Am I specifying it wrong?

--
JHHL

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

Problem with protocols, Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[James H. H. Lampert]

Running two connectors seems to work just fine, but I'm having trouble 
getting one of them to only take TLS 1.2


In reply to my query:


Given all this, is it possible to (1) have Tomcat listen on two separate
HTTPS ports, and (2) have one of the ports require TLS 1.2, but the
other accept something our AS/400 can use?


On 7/17/20 10:03 AM, Mark Thomas wrote:


Yes. You need two Connector elements specifying different ports and
different protocols. They should be able to use the same certificate
configuration.


I just ran a test on our development Amazon EC2 instance, and verified 
that I could listen on two different ports (existing 8443 and now 7443), 
and I limited (or so I thought) 8443 (to which I have 443 rerouted 
through iptables) to TLS 1.2.


Except that SSLLabs tells me it's still accepting TLS 1.0 and 1.1!

I commented out the connector for 8443 and restarted Tomcat, but it's 
still giving the same report from SSLLabs.


The connector for 8443 in server.xml looks like this (lines truncated):




The 'sslProtocol="TLSv1.2"' clause is copied directly from the Tomcat 7 
installation on our most security-conscious customer's AS/400; this 
Tomcat is 8.5. Am I specifying it wrong?


--
JHHL

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

RE: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[jonmcalexander]

It works quite well.

Sorry for the top post, I only have outlook and it sucks in this respect.


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Mark Thomas  
Sent: Friday, July 17, 2020 12:03 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS issue: can we listen on more than one secured port, with 
different protocols enabled?

On 17/07/2020 17:55, James H. H. Lampert wrote:
> I've got an issue here.
> 
> On the one hand, we have a Tomcat server running on Amazon (in a 
> Beanstalk cluster). And we have an AS/400 running an old enough OS 
> that, so far as I'm aware, cannot be configured to use TLS 1.2 at the 
> current OS release level. And that AS/400 needs to access that Tomcat 
> server (which it does, using Scott Klement's open source HTTPAPI 
> product, which has become pretty much an industry standard for the purpose).
> 
> And on the other hand, we are getting a security report from SSLLabs, 
> telling us that our security rating is capped at "B" because we allow 
> TLS 1.0 and 1.1.
> 
> BUT, our entire office is on a static IP address, and we already know 
> how to open a port on our Amazon firewall to only accept traffic from 
> our office IP.
> 
> Given all this, is it possible to (1) have Tomcat listen on two 
> separate HTTPS ports, and (2) have one of the ports require TLS 1.2, 
> but the other accept something our AS/400 can use?

Yes. You need two Connector elements specifying different ports and different 
protocols. They should be able to use the same certificate configuration.

Mark

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

Re: SSL/TLS issue: can we listen on more than one secured port, with different protocols enabled?

[Mark Thomas]

On 17/07/2020 17:55, James H. H. Lampert wrote:
> I've got an issue here.
> 
> On the one hand, we have a Tomcat server running on Amazon (in a
> Beanstalk cluster). And we have an AS/400 running an old enough OS that,
> so far as I'm aware, cannot be configured to use TLS 1.2 at the current
> OS release level. And that AS/400 needs to access that Tomcat server
> (which it does, using Scott Klement's open source HTTPAPI product, which
> has become pretty much an industry standard for the purpose).
> 
> And on the other hand, we are getting a security report from SSLLabs,
> telling us that our security rating is capped at "B" because we allow
> TLS 1.0 and 1.1.
> 
> BUT, our entire office is on a static IP address, and we already know
> how to open a port on our Amazon firewall to only accept traffic from
> our office IP.
> 
> Given all this, is it possible to (1) have Tomcat listen on two separate
> HTTPS ports, and (2) have one of the ports require TLS 1.2, but the
> other accept something our AS/400 can use?

Yes. You need two Connector elements specifying different ports and
different protocols. They should be able to use the same certificate
configuration.

Mark

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

RE: SSL error [EXTERNAL]

[Beard, Shawn M.]

I was able to resolve this. I used keytool to create a new keystore/trust 
store, then imported the previous truststore that had all the CA certs in it. 
That seemed to work. So even though the previous truststore had the certs in it 
and was not empty, it must have had some kind of linking problem maybe?



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: john.e.gr...@wellsfargo.com.INVALID 
Sent: Friday, June 26, 2020 1:32 PM
To: users@tomcat.apache.org
Subject: RE: SSL error [EXTERNAL]

** CAUTION: External message


Shawn,


-Original Message-
From: Beard, Shawn M. 
Sent: Friday, June 26, 2020 11:57 AM
To: Tomcat Users List 
Subject: RE: SSL error [EXTERNAL]

The code is calling a new webservice. It has godaddy as its ca signer. It was 
getting the error before I added those java options. Those java options were my 
attempt to resolve it. Ive also tried adding the godaddy ca certs to java's 
cacert file without those java options. Same result.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: calder 
Sent: Friday, June 26, 2020 11:45 AM
To: Tomcat Users List 
Subject: Re: SSL error [EXTERNAL]

** CAUTION: External message


In Fri, Jun 26, 2020, 10:37 Beard, Shawn M. 
wrote:

> We are running tomcat-7.0.52(old I know) and java 1.7.0_80.
>

yea, BOTH are very old.

When the app makes calls to an external webservice. It keeps throwing this
> error:
>
> javax.net.ssl.SSLException : javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
>
[1]

> I have this in the java options and have confirmed the proper CA certs
> for this webservice is in the truststore. Any ideas?
>
-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.trustStoreType=jks
>

Did this runtime EVER work?

If yes, "what" changed?



[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty__;!!Li8W9_Um1Taa!uk48yx6ZQNHjmcqPmjBlJDFCcCWu6HMZu3OI_Yau1oJ4CBGoaFzI0pfKTaIrqOGk$
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.
B CB  [  
X  ܚX KK[XZ[  \ \  ][  X  ܚX P X ]  \X K ܙ B  ܈Y][ۘ[  [X[  
K[XZ[  \ \  Z[ X ]  \X K ܙ B

That error message comes from PKIXParameters.setTrustAnchors().  I was able to 
reproduce the problem with an empty trust store.  I also tried a trust store 
with the wrong certs but got a different error.

With -Djavax.net.debug=ssl, you should see output like this:

trustStore is: /path/to/trust.jks
trustStore type is: jks
trustStore provider is:
the last modified time is: Fri Jun 26 13:27:52 CDT 2020 Reload the trust store 
Reload trust certs Reloaded 1 trust certs adding as trusted cert:

Followed by a list of certs found in the store.

Is that what's happening in your case?

John

Т ХF  V 
7V'67&  R   â W6W'2 V 7V'67&  F  6B 6 R  Фf "FF F    6    G2 
R   â W6W'2ֆV  F  6B 6 R  Р

RE: SSL error [EXTERNAL]

[John.E.Gregg]

Shawn,


-Original Message-
From: Beard, Shawn M.  
Sent: Friday, June 26, 2020 11:57 AM
To: Tomcat Users List 
Subject: RE: SSL error [EXTERNAL]

The code is calling a new webservice. It has godaddy as its ca signer. It was 
getting the error before I added those java options. Those java options were my 
attempt to resolve it. Ive also tried adding the godaddy ca certs to java's 
cacert file without those java options. Same result.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: calder 
Sent: Friday, June 26, 2020 11:45 AM
To: Tomcat Users List 
Subject: Re: SSL error [EXTERNAL]

** CAUTION: External message


In Fri, Jun 26, 2020, 10:37 Beard, Shawn M. 
wrote:

> We are running tomcat-7.0.52(old I know) and java 1.7.0_80.
>

yea, BOTH are very old.

When the app makes calls to an external webservice. It keeps throwing this
> error:
>
> javax.net.ssl.SSLException : javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors 
> parameter must be non-empty
>
[1]

> I have this in the java options and have confirmed the proper CA certs 
> for this webservice is in the truststore. Any ideas?
>
-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.trustStoreType=jks
>

Did this runtime EVER work?

If yes, "what" changed?



[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty__;!!Li8W9_Um1Taa!uk48yx6ZQNHjmcqPmjBlJDFCcCWu6HMZu3OI_Yau1oJ4CBGoaFzI0pfKTaIrqOGk$
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.
B CB  [  
X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B 

That error message comes from PKIXParameters.setTrustAnchors().  I was able to 
reproduce the problem with an empty trust store.  I also tried a trust store 
with the wrong certs but got a different error.

With -Djavax.net.debug=ssl, you should see output like this:

trustStore is: /path/to/trust.jks
trustStore type is: jks
trustStore provider is: 
the last modified time is: Fri Jun 26 13:27:52 CDT 2020
Reload the trust store
Reload trust certs
Reloaded 1 trust certs
adding as trusted cert:

Followed by a list of certs found in the store.

Is that what's happening in your case?

John

RE: SSL error [EXTERNAL]

[Beard, Shawn M.]

The code is calling a new webservice. It has godaddy as its ca signer. It was 
getting the error before I added those java options. Those java options were my 
attempt to resolve it. Ive also tried adding the godaddy ca certs to java's 
cacert file without those java options. Same result.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: calder 
Sent: Friday, June 26, 2020 11:45 AM
To: Tomcat Users List 
Subject: Re: SSL error [EXTERNAL]

** CAUTION: External message


In Fri, Jun 26, 2020, 10:37 Beard, Shawn M. 
wrote:

> We are running tomcat-7.0.52(old I know) and java 1.7.0_80.
>

yea, BOTH are very old.

When the app makes calls to an external webservice. It keeps throwing this
> error:
>
> javax.net.ssl.SSLException : javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
>
[1]

> I have this in the java options and have confirmed the proper CA certs
> for this webservice is in the truststore. Any ideas?
>
-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.trustStoreType=jks
>

Did this runtime EVER work?

If yes, "what" changed?



[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty__;!!Li8W9_Um1Taa!uk48yx6ZQNHjmcqPmjBlJDFCcCWu6HMZu3OI_Yau1oJ4CBGoaFzI0pfKTaIrqOGk$
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

Re: SSL error

[calder]

In Fri, Jun 26, 2020, 10:37 Beard, Shawn M. 
wrote:

> We are running tomcat-7.0.52(old I know) and java 1.7.0_80.
>

yea, BOTH are very old.

When the app makes calls to an external webservice. It keeps throwing this
> error:
>
> javax.net.ssl.SSLException : javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
>
[1]

> I have this in the java options and have confirmed the proper CA certs for
> this webservice is in the truststore. Any ideas?
>
-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.trustStoreType=jks
>

Did this runtime EVER work?

If yes, "what" changed?



[1]
https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty

RE: SSL issue : java.security.KeyStoreException: Cannot store non-PrivateKeys

[Venkataraman Srinivasan]

John,

Thanks for your response.

But we have not set any JAVA_OPTS or CATALINA_OPTS in our environment.

>From Apache Tomcat perspective what value have we to give for them?

Thanks
Venkat



>>>  9/26/2019 6:35 PM >>>
Sounds like you need to share your JAVA_OPTS or CATALINA_OPTS, not your 
connector.


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

From: Venkataraman Srinivasan 
Sent: Thursday, September 26, 2019 4:30 PM
To: users@tomcat.apache.org 
Subject: SSL issue : java.security.KeyStoreException: Cannot store 
non-PrivateKeys


Hi,

I am getting below error while I am starting TOMCAT

Caused by: java.lang.IllegalArgumentException: Cannot store non-PrivateKeys
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:116)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:87)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1086)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:268)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
... 13 more
Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
at 
sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:250)
at 
sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:55)
at java.security.KeyStore.setKeyEntry(KeyStore.java:909)
at org.apache.tomcat.util.net.jsse.
++

Environment :

Tomcat Version : 8.5.32
Certificate Issuer : Thawte
KeyStore created with : Key Algorithm RSA
CSR Requested with : < NO Key Alogorithm is pased>
Certificate Signature algorithm name: SHA1withRSA


Connector Entry in server.xml



  sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
  defaultSSLHostConfigName="https://blabla.bla.org:8443;
  protocol="org.apache.coyote.http11.Http11NioProtocol"
  maxThreads="200"
  enableLookups="false"
  clientAuth="false"
  acceptCount="10"
  SSLEnabled="true"
  connectionTimeout="6"
  
  https://blabla.bla.org:8443; >

  sslProtocols="+TLS+TLSv1.2+TLSv1.3"
  
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"
   
   


Thanks
Venkat




--

This email has been scanned for spam and viruses. Visit the following link to 
report this email as spam:
https://attseg.cloud-protect.net/index01.php?mod_id=11_option=logitem_id=1569537883-jE3ZMjV4cMGi_address=venkataraman.srinivasan%40gcrta.org=1
 


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

Re: SSL issue : java.security.KeyStoreException: Cannot store non-PrivateKeys

[Rémy Maucherat]

On Fri, Sep 27, 2019 at 9:40 AM Mark Thomas  wrote:

> >  >   certificateFile="key_store/ssl_certificate.p7b"
> >   certificateAlias="bla"
> >   keystoreFile="/key_store/blabla.jks" type="RSA"
> >   keystoreType="JKS"
> >   keyChainFile="key_store/linux_apex_inter_x509.cer"
> >   keystorePassword="
>
> We need to exactly how each of the following files were created and/or
> exactly what is in each file:
>
> - ssl_certificate.p7b
> - blabla.jks
> - linux_apex_inter_x509.cer
>
> It might be as simple as you need to import the p7b file into the
> keystore and remove the certificateFile setting. But that is just a wild
> guess without knowing what is in those files.
>

I'm a bit lost here.

Normally certificateFile and keystoreFile should be "exclusive" (if
keystoreFile is set, then certificateFile will be ignored - it seems it
could be nice to add a warning ...), and I don't know about a keyChainFile
attribute either (I verified I get a proper "WARNING [main]
org.apache.catalina.startup.SetAllPropertiesRule.begin
[SetAllPropertiesRule]{Server/Service/Connector/SSLHostConfig/Certificate}
Setting property 'keyChainFile' to 'foobar' did not find a matching
property." in my logs).

So the config should be looked at again first, I think only keystoreFile
will be used and it will be the cause of the error.

Since you made plenty of special cases fixes since 8.5.32 for this, Venkat
should probably first test again with 8.5.46 (IMO).

Rémy


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

Re: SSL issue : java.security.KeyStoreException: Cannot store non-PrivateKeys

[Mark Thomas]

On 26/09/2019 22:30, Venkataraman Srinivasan wrote:
> 
> Hi,
>  
> I am getting below error while I am starting TOMCAT
>  
> Caused by: java.lang.IllegalArgumentException: Cannot store non-PrivateKeys



This looks like it is related to the work we have been doing to make it
easy to swap between JSSE and OpenSSL based Connectors. In the
background Tomcat creates an in-memory keystore for each certificate and
then provides the key / cert / chain in the the right format for the TLS
implementation.

We have already found a few "interesting" configuration combinations
that needed specific handling. This may be one - or it may be an invalid
configuration.

We need to be able to recreate this problem. With that in mind...



>        certificateFile="key_store/ssl_certificate.p7b"
>   certificateAlias="bla"
>   keystoreFile="/key_store/blabla.jks" type="RSA"
>   keystoreType="JKS"
>   keyChainFile="key_store/linux_apex_inter_x509.cer"
>   keystorePassword="

We need to exactly how each of the following files were created and/or
exactly what is in each file:

- ssl_certificate.p7b
- blabla.jks
- linux_apex_inter_x509.cer

It might be as simple as you need to import the p7b file into the
keystore and remove the certificateFile setting. But that is just a wild
guess without knowing what is in those files.

Mark


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

RE: SSL issue : java.security.KeyStoreException: Cannot store non-PrivateKeys

[jonmcalexander]

Sounds like you need to share your JAVA_OPTS or CATALINA_OPTS, not your 
connector.


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

From: Venkataraman Srinivasan 
Sent: Thursday, September 26, 2019 4:30 PM
To: users@tomcat.apache.org
Subject: SSL issue : java.security.KeyStoreException: Cannot store 
non-PrivateKeys


Hi,

I am getting below error while I am starting TOMCAT

Caused by: java.lang.IllegalArgumentException: Cannot store non-PrivateKeys
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:116)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:87)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1086)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:268)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
... 13 more
Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
at 
sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:250)
at 
sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:55)
at java.security.KeyStore.setKeyEntry(KeyStore.java:909)
at org.apache.tomcat.util.net.jsse.
++

Environment :

Tomcat Version : 8.5.32
Certificate Issuer : Thawte
KeyStore created with : Key Algorithm RSA
CSR Requested with : < NO Key Alogorithm is pased>
Certificate Signature algorithm name: SHA1withRSA


Connector Entry in server.xml



  sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
  defaultSSLHostConfigName="https://blabla.bla.org:8443;
  protocol="org.apache.coyote.http11.Http11NioProtocol"
  maxThreads="200"
  enableLookups="false"
  clientAuth="false"
  acceptCount="10"
  SSLEnabled="true"
  connectionTimeout="6"
  
  https://blabla.bla.org:8443; >

  sslProtocols="+TLS+TLSv1.2+TLSv1.3"
  
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"
   
   


Thanks
Venkat

Re: SSL Certificate Renewal

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nitin,

On 6/18/19 13:50, Nitin Kadam wrote:
> Hello,
> 
> I want to renew current SSL certificate So I am confused. Do I need
> to recreate keystore and csr for new certificate.
> 
> If I have to create new keystore, how I can create same on existing
> running setup.

You do not need to create a new key, but it would be a goods idea to
create a new one, just in case your old key has been compromised. It's
really not that complicated to create a new key.

Keep your old keystore with no changes. Create a new keystore with a
new key and new certificate. Get the cert signed by a CA and import
the signed cert back into your keystore, along with any of the CA's
intermediate certificates that may be necessary.

This process has been documented many many times on the web.

- -chris

> On Thu, Jun 13, 2019, 12:11 PM Ognjen Blagojevic < 
> ognjen.d.blagoje...@gmail.com> wrote:
> 
>> Nitin,
>> 
>> On 13.6.2019. 07.37, Nitin Kadam wrote:
>>> I have apache tomcat server running with publicly signed SSL
>>> certificate configured in server.xml, the same certificate is
>>> expiring in next week,
>> I
>>> need steps to the to renew of same. *Server OS: Windows 2012
>>> R2* *Apache Tomcat/8.5.38*
>>> 
>>> 1. How to generate new CSR with new key alias 2. How to import
>>> the new. cert & intermediate certificate chain in .jks format 
>>> 3. what about keystore & current key alias
>>> 
>>> 
>>> kindly guide me, as I will be performing same first time.
>> 
>> You can find instructions here:
>> 
>> 
>> http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Installing_a_C
ertificate_from_a_Certificate_Authority
>>
>>
>> 
Regards,
>> Ognjen
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0JelUACgkQHPApP6U8
pFhG9Q//YUAnPWCgn5LrQrY3KUgj0QIp72vH61MB2zdSs85rfIBLwEXOfALtomHf
p24uRxNvn8hqx8BPRrxwM0Zf2Q0YHd9pBdTww1bb9xTwILqzBQTuzrac8DNnHUDW
HXdOyej3tKiPD0e5Wp9AE9aFoE/56/uqxDTej5bGbE7/Prbwf7ynlNsetHMzBA/u
BOzE7TpJjxDdmqOIm87JGZtrfDGIIV7xzAdZySg6QtkeD7ieSOrIkrBrToUU2MJG
53n79iEJn+yKWCjtfTBG2mWOT9zwCevNo2VjMk6ql2BbVtlCJ6j8RQeEqpnzEtHB
BEECiSAnfRE8wuJ6Ajq/dL3mYcCZrlRyA6XMDA/7GPoiNrlW/cYJ1uxpFbxMiJnm
yX3elf16CgBPRm7yg/TbGqihDIpUtRSWAIhTsa56EzvYV1msqCWt8iWkbOBeeyEd
UyLaP95N0EDptXIgrgOV1dodyDfKDvjgG9KXfiCEI9Owg9Ka73zffGWuB1Af5P/d
+k90Oak8hrDhNjD1E3oqm3wmHi+4rPAH66thxk5M3SV7yRmh+9mbO7XgvPw77EA6
0iWD/JvXOgUw2p/i0Mp4vWMlKE6wLTh4ER/5PKHXK1ZVoD2NfISjky0cpsxmHs/w
7VxnLDDqFyIqaXvDwHaqs0jzL2BWn/V/7ucavFYf7RDeoyg0kh4=
=Du+S
-END PGP SIGNATURE-

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

Re: SSL Certificate Renewal

[Nitin Kadam]

Hello,

I want to renew current SSL certificate
So I am confused.
Do I need to recreate keystore and csr for new certificate.

If I have to create new keystore, how I can create same on existing running
setup.


On Thu, Jun 13, 2019, 12:11 PM Ognjen Blagojevic <
ognjen.d.blagoje...@gmail.com> wrote:

> Nitin,
>
> On 13.6.2019. 07.37, Nitin Kadam wrote:
> > I have apache tomcat server running with publicly signed SSL certificate
> > configured in server.xml, the same certificate is expiring in next week,
> I
> > need steps to the to renew of same.
> > *Server OS: Windows 2012 R2*
> > *Apache Tomcat/8.5.38*
> >
> > 1. How to generate new CSR with new key alias
> > 2. How to import the new. cert & intermediate certificate chain in .jks
> > format
> > 3. what about keystore & current key alias
> >
> >
> > kindly guide me, as I will be performing same first time.
>
> You can find instructions here:
>
>
> http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Installing_a_Certificate_from_a_Certificate_Authority
>
> Regards,
> Ognjen
>

Re: SSL Certificate Renewal

[Ognjen Blagojevic]

Nitin

On 13.6.2019. 07.37, Nitin Kadam wrote:

I have apache tomcat server running with publicly signed SSL certificate
configured in server.xml, the same certificate is expiring in next week, I
need steps to the to renew of same.
*Server OS: Windows 2012 R2*
*Apache Tomcat/8.5.38*

1. How to generate new CSR with new key alias
2. How to import the new. cert & intermediate certificate chain in .jks
format
3. what about keystore & current key alias


kindly guide me, as I will be performing same first time.


You can find the instructions here:

http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Installing_a_Certificate_from_a_Certificate_Authority

Regards,
Ognjen

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

Re: SSL certificate error in Tomcat 9

[Mark Thomas]

On 12/06/2019 15:45, Support wrote:
> Hi Sir,
> I am using tomcat 9 for my application.
> 
> I got an error with the .keystore file for SSL certificate
> 
> this is my code is this still valid? in tomcat 9
> 
>  maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/home/myapp/.keystore" keystorePass="Password"
> sslEnabledProtocols="TLSv1.2"
>   />

No. Your protocol value is not valid. The BIO connector has been
removed. You probably want NIO.

See:
http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Common_Attributes

Search for protocol.

Mark


> 
> 
> 
> Logs:
> 
> 
> 12-Jun-2019 14:19:03.973 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'maxThreads' to '150' did not find a matching property.
> 12-Jun-2019 14:19:03.973 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'SSLEnabled' to 'true' did not find a matching property.
> 12-Jun-2019 14:19:03.973 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'clientAuth' to 'false' did not find a matching property.
> 12-Jun-2019 14:19:03.973 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'sslProtocol' to 'TLS' did not find a matching property.
> 12-Jun-2019 14:19:03.973 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'keystoreFile' to '/home/myPP/.keystore' did not find a matching property.
> 12-Jun-2019 14:19:03.973 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'keystorePass' to 'PASSWORD' did not find a matching property.
> 12-Jun-2019 14:19:03.974 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'sslEnabledProtocols' to 'TLSv1.2' did not find a matching property.
> 
> Regards,
> Sandeep Raghav
> 
> Customer Support Engineer
> supp...@xcaptor.com
> Captivate. Engage.
> 


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

Re: SSL Errors and Warnings with various version of Tomcat

[Richard Tearle]

On Tue, 13 Nov 2018 at 14:10, Mark Thomas  wrote:
>
> On 13/11/2018 14:00, Rémy Maucherat wrote:
> > On Tue, Nov 13, 2018 at 2:50 PM Richard Tearle <
> > richard.tea...@northgateps.com> wrote:
> >
> >> Hi
> >>
> >> Our applications are all working fine with Tomcat 8.5.34 and Tomcat
> >> Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
> >> Java JRE 8u172
> >>
> >> On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
> >> following warning:
> >>
> >> 12-Nov-2018 14:37:03.459 WARNING [main]
> >> org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
> >> getting cipher list
> >>  java.lang.Exception: Invalid Server SSL Protocol
> >> (error::lib(0):func(0):reason(0))
> >> at org.apache.tomcat.jni.SSLContext.make(Native Method)
> >> at org.apache.tomcat.util.net
> >> .openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
> >>
> >
> > There was a patch porting problem in 8.5 in the jni.SSL class.
>
> Sorry. My mistake.
>
> I'll get the necessary fix back-ported for the next 8.5.x release.
>
> Mark

OK - so I just hold off until the next release - we can live with that.

Thanks all!

Richard

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

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: SSL Errors and Warnings with various version of Tomcat

[Mark Thomas]

On 13/11/2018 14:00, Rémy Maucherat wrote:
> On Tue, Nov 13, 2018 at 2:50 PM Richard Tearle <
> richard.tea...@northgateps.com> wrote:
> 
>> Hi
>>
>> Our applications are all working fine with Tomcat 8.5.34 and Tomcat
>> Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
>> Java JRE 8u172
>>
>> On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
>> following warning:
>>
>> 12-Nov-2018 14:37:03.459 WARNING [main]
>> org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
>> getting cipher list
>>  java.lang.Exception: Invalid Server SSL Protocol
>> (error::lib(0):func(0):reason(0))
>> at org.apache.tomcat.jni.SSLContext.make(Native Method)
>> at org.apache.tomcat.util.net
>> .openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
>>
> 
> There was a patch porting problem in 8.5 in the jni.SSL class.

Sorry. My mistake.

I'll get the necessary fix back-ported for the next 8.5.x release.

Mark

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

Re: SSL Errors and Warnings with various version of Tomcat

[Rémy Maucherat]

On Tue, Nov 13, 2018 at 2:50 PM Richard Tearle <
richard.tea...@northgateps.com> wrote:

> Hi
>
> Our applications are all working fine with Tomcat 8.5.34 and Tomcat
> Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
> Java JRE 8u172
>
> On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
> following warning:
>
> 12-Nov-2018 14:37:03.459 WARNING [main]
> org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
> getting cipher list
>  java.lang.Exception: Invalid Server SSL Protocol
> (error::lib(0):func(0):reason(0))
> at org.apache.tomcat.jni.SSLContext.make(Native Method)
> at org.apache.tomcat.util.net
> .openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
>

There was a patch porting problem in 8.5 in the jni.SSL class.

Rémy

AW: [bulk] Re: SSL on Tomcat

[Mario Schmitz]

Hey,

arbeitet ihr gerade irgendwo?

Hier hier gerade alle Anwendungen von außen  nicht erreichbar gewesen. Über 
intern ging ...

LG
Mario

-Ursprüngliche Nachricht-
Von: Loai Abdallatif [mailto:loai.abdalla...@gmail.com] 
Gesendet: Dienstag, 2. Oktober 2018 09:07
An: Tomcat Users List 
Betreff: [bulk] Re: SSL on Tomcat

Thanks Chris, Luis

On Tue, Oct 2, 2018 at 10:00 AM Luis Rodríguez Fernández 
wrote:

> Hello Christopher,
>
> It makes sense, thank you very much for your advice!
>
> Cheers,
>
> Luis
>
> El lun., 1 oct. 2018 a las 20:39, Christopher Schultz (<
> ch...@christopherschultz.net>) escribió:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Luis,
> >
> > On 10/1/18 11:06 AM, Luis Rodríguez Fernández wrote:
> > > Agree with Christopher, you have to fix your client. Just get the 
> > > root Certificate Authority public key and import it in your client 
> > > truststore.
> >
> > I'd recommend trusting the finest-grained cert you can get away with.
> > That might not always be the root CA cert. It might be the server's 
> > cert directly.
> >
> > > If you did not change it the client (java) the default keystore is 
> > > located in  $JAVA_HOME/jre/lib/security/cacerts. Something like:
> > >
> > > keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts
> > > -storepass trust_store_password_here -alias Root -import -file 
> > > the_downloaded_ca.crt
> > >
> > > The default password for cacerts is changeit
> >
> > FWIW, I wouldn't recommend changing the JVM's trust store. I say so 
> > for two reasons:
> >
> > 1. You will be trusting that certificate for ALL JVMS LAUNCHED 
> > AFTERWARD. Perhaps you don't want some other service to trust your
> > 192.168.1.120 certificate when it's only supposed to be used with a 
> > single client service.
> >
> > 2. You will have to remember to update the trust store every time 
> > you change your Java installation. That means upgrades, downgrades, etc.
> >
> > The best way to do this IMO is to create a trust store specific for 
> > that service (client) and use it EXPLICITLY.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluyafIACgkQHPApP6U8
> > pFijGRAAr8BXcoObcsRM/n++276xFYoAJPGKigExp6wpLjI0iHasPpXC0BPaMInb
> > w7ZkgwAY77Qq7jCcUB8FGrBQXo+axN2r8MVsghV/UyTIwnZyKDM0lb4z6d6016Bc
> > fQjoalUal857FH20PRAv5U+GrrpNcE7Mua5yu6eTqlMpX2hC0kBCc+oaH6xmtZr/
> > lvtn9UK5/ymS83yW5sxxYRa3uEnFf6U2EFJoWKGraEOHquEiX01Jn5nOYxccyPMT
> > TtjZ+yzkc/gvBTsme0ZVdOXTK9m+0Q10f/Fgc4bidSb9ZybaBcm8YsOqpqjP9poC
> > YU4KtJP7BsJbMVzNV7YFlmIDlOVXwzk84oqEj8trbUe8AtJnq9gCLFp6/1ElmXE4
> > xP26Gw1ck2vqQC/4u43HsiBegLFaBUorjNw3fWkf3PTiqSXHjXToJK9oYRv1DNkr
> > SV8dlnujLbqmDQWag2FHTkE6Ka5sFBdbeFUdFP0Qd7jkhmErr5nziO1RtZ1bkIUz
> > MaCYdpLR+OdU1XMrENnLHRedmpjDXp4UA1/mqr/PSMadQrlK7Z4fF5UVurXFWn7Z
> > C+HNYzoSmvUL+y1KsficoK3ZGthUpkgApFFbFh3aSKdm07V+Xt1KK6sRndcjdoff
> > KtU/sG0d0SSLnJmRCJHINRSOccmHZUiWGJ9+UXXE2Gd4nEw43r4=
> > =okQm
> > -END PGP SIGNATURE-
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> --
>
> "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
>
> - Samuel Beckett
>

Re: SSL on Tomcat

[Loai Abdallatif]

Thanks Chris, Luis

On Tue, Oct 2, 2018 at 10:00 AM Luis Rodríguez Fernández 
wrote:

> Hello Christopher,
>
> It makes sense, thank you very much for your advice!
>
> Cheers,
>
> Luis
>
> El lun., 1 oct. 2018 a las 20:39, Christopher Schultz (<
> ch...@christopherschultz.net>) escribió:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Luis,
> >
> > On 10/1/18 11:06 AM, Luis Rodríguez Fernández wrote:
> > > Agree with Christopher, you have to fix your client. Just get the
> > > root Certificate Authority public key and import it in your client
> > > truststore.
> >
> > I'd recommend trusting the finest-grained cert you can get away with.
> > That might not always be the root CA cert. It might be the server's
> > cert directly.
> >
> > > If you did not change it the client (java) the default keystore is
> > > located in  $JAVA_HOME/jre/lib/security/cacerts. Something like:
> > >
> > > keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts
> > > -storepass trust_store_password_here -alias Root -import -file
> > > the_downloaded_ca.crt
> > >
> > > The default password for cacerts is changeit
> >
> > FWIW, I wouldn't recommend changing the JVM's trust store. I say so
> > for two reasons:
> >
> > 1. You will be trusting that certificate for ALL JVMS LAUNCHED
> > AFTERWARD. Perhaps you don't want some other service to trust your
> > 192.168.1.120 certificate when it's only supposed to be used with a
> > single client service.
> >
> > 2. You will have to remember to update the trust store every time you
> > change your Java installation. That means upgrades, downgrades, etc.
> >
> > The best way to do this IMO is to create a trust store specific for
> > that service (client) and use it EXPLICITLY.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluyafIACgkQHPApP6U8
> > pFijGRAAr8BXcoObcsRM/n++276xFYoAJPGKigExp6wpLjI0iHasPpXC0BPaMInb
> > w7ZkgwAY77Qq7jCcUB8FGrBQXo+axN2r8MVsghV/UyTIwnZyKDM0lb4z6d6016Bc
> > fQjoalUal857FH20PRAv5U+GrrpNcE7Mua5yu6eTqlMpX2hC0kBCc+oaH6xmtZr/
> > lvtn9UK5/ymS83yW5sxxYRa3uEnFf6U2EFJoWKGraEOHquEiX01Jn5nOYxccyPMT
> > TtjZ+yzkc/gvBTsme0ZVdOXTK9m+0Q10f/Fgc4bidSb9ZybaBcm8YsOqpqjP9poC
> > YU4KtJP7BsJbMVzNV7YFlmIDlOVXwzk84oqEj8trbUe8AtJnq9gCLFp6/1ElmXE4
> > xP26Gw1ck2vqQC/4u43HsiBegLFaBUorjNw3fWkf3PTiqSXHjXToJK9oYRv1DNkr
> > SV8dlnujLbqmDQWag2FHTkE6Ka5sFBdbeFUdFP0Qd7jkhmErr5nziO1RtZ1bkIUz
> > MaCYdpLR+OdU1XMrENnLHRedmpjDXp4UA1/mqr/PSMadQrlK7Z4fF5UVurXFWn7Z
> > C+HNYzoSmvUL+y1KsficoK3ZGthUpkgApFFbFh3aSKdm07V+Xt1KK6sRndcjdoff
> > KtU/sG0d0SSLnJmRCJHINRSOccmHZUiWGJ9+UXXE2Gd4nEw43r4=
> > =okQm
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> --
>
> "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
>
> - Samuel Beckett
>

Re: SSL on Tomcat

[Luis Rodríguez Fernández]

Hello Christopher,

It makes sense, thank you very much for your advice!

Cheers,

Luis

El lun., 1 oct. 2018 a las 20:39, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Luis,
>
> On 10/1/18 11:06 AM, Luis Rodríguez Fernández wrote:
> > Agree with Christopher, you have to fix your client. Just get the
> > root Certificate Authority public key and import it in your client
> > truststore.
>
> I'd recommend trusting the finest-grained cert you can get away with.
> That might not always be the root CA cert. It might be the server's
> cert directly.
>
> > If you did not change it the client (java) the default keystore is
> > located in  $JAVA_HOME/jre/lib/security/cacerts. Something like:
> >
> > keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts
> > -storepass trust_store_password_here -alias Root -import -file
> > the_downloaded_ca.crt
> >
> > The default password for cacerts is changeit
>
> FWIW, I wouldn't recommend changing the JVM's trust store. I say so
> for two reasons:
>
> 1. You will be trusting that certificate for ALL JVMS LAUNCHED
> AFTERWARD. Perhaps you don't want some other service to trust your
> 192.168.1.120 certificate when it's only supposed to be used with a
> single client service.
>
> 2. You will have to remember to update the trust store every time you
> change your Java installation. That means upgrades, downgrades, etc.
>
> The best way to do this IMO is to create a trust store specific for
> that service (client) and use it EXPLICITLY.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluyafIACgkQHPApP6U8
> pFijGRAAr8BXcoObcsRM/n++276xFYoAJPGKigExp6wpLjI0iHasPpXC0BPaMInb
> w7ZkgwAY77Qq7jCcUB8FGrBQXo+axN2r8MVsghV/UyTIwnZyKDM0lb4z6d6016Bc
> fQjoalUal857FH20PRAv5U+GrrpNcE7Mua5yu6eTqlMpX2hC0kBCc+oaH6xmtZr/
> lvtn9UK5/ymS83yW5sxxYRa3uEnFf6U2EFJoWKGraEOHquEiX01Jn5nOYxccyPMT
> TtjZ+yzkc/gvBTsme0ZVdOXTK9m+0Q10f/Fgc4bidSb9ZybaBcm8YsOqpqjP9poC
> YU4KtJP7BsJbMVzNV7YFlmIDlOVXwzk84oqEj8trbUe8AtJnq9gCLFp6/1ElmXE4
> xP26Gw1ck2vqQC/4u43HsiBegLFaBUorjNw3fWkf3PTiqSXHjXToJK9oYRv1DNkr
> SV8dlnujLbqmDQWag2FHTkE6Ka5sFBdbeFUdFP0Qd7jkhmErr5nziO1RtZ1bkIUz
> MaCYdpLR+OdU1XMrENnLHRedmpjDXp4UA1/mqr/PSMadQrlK7Z4fF5UVurXFWn7Z
> C+HNYzoSmvUL+y1KsficoK3ZGthUpkgApFFbFh3aSKdm07V+Xt1KK6sRndcjdoff
> KtU/sG0d0SSLnJmRCJHINRSOccmHZUiWGJ9+UXXE2Gd4nEw43r4=
> =okQm
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Re: SSL on Tomcat

[Loai Abdallatif]

thanks very much , I did it and it works

On Mon, Oct 1, 2018 at 6:07 PM Luis Rodríguez Fernández 
wrote:

> Hello Loai,
>
> Agree with Christopher, you have to fix your client. Just get the root
> Certificate Authority public key and import it in your client truststore.
> If you did not change it the client (java) the default keystore is located
> in  $JAVA_HOME/jre/lib/security/cacerts. Something like:
>
>  keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass
> trust_store_password_here -alias Root -import -file the_downloaded_ca.crt
>
> The default password for cacerts is changeit
>
> Hopeit helps,
>
> Luis
>
>
>
>
> El sáb., 29 sept. 2018 a las 12:05, Loai Abdallatif (<
> loai.abdalla...@gmail.com>) escribió:
>
> > Thanks Chris, but how to do it, should I copy the ssl certificate from
> > Webserver 192.168.1.120 to my tomcat container (worker0) in 192.168.1.111
> > in server.xml .
> > any idea please
> >
> > On Sat, Sep 29, 2018 at 1:35 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Loai,
> > >
> > > On 9/27/18 10:50, Loai Abdallatif wrote:
> > > > Hello,
> > > >
> > > > I have Set Apache Load Balancer ( ModJK) with Server IP
> > > > 192.168.1.120 (Webserver01.epsilon.test)  which forward the traffic
> > > > to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
> > > >
> > > > each tomcat server has three workers ( 0,1,2)
> > > >
> > > > I deployed *Central Authentication Service* (CAS)  on Worker0  and
> > > > its is working with warning related to ssl Certificate, I have
> > > > another Application on this worker0 called ServiceCatalog
> > > > unfortunatly it didnt work and gave error as below
> > > >
> > > >
> > > > ERROR org.jasig.cas.client.util.CommonUtils -
> > > > sun.security.validator.ValidatorException: PKIX path building
> > > > failed
> > > >  : sun.security.provider.certpath.SunCertPathBuilderException:
> > > > unable to find valid certification path to requested
> > > >  target javax.net.ssl.SSLHandshakeException:
> > > > sun.security.validator.ValidatorException: PKIX path building
> > > > failed: sun.sec
> > > >  urity.provider.certpath.SunCertPathBuilderException: unable to
> > > > find valid certification path to requested target
> > >
> > > As Guido says, your client (org.jasig.cas.client) does not trust the
> > > server it's trying to connect to.
> > >
> > > Is the server in this case the one you set up above? It's not clear
> > > exactly what you are trying to do.
> > >
> > > There is nothing you can change with Tomcat to fix this error... you
> > > must configure your client to trust the server.
> > >
> > > - -chris
> > > -BEGIN PGP SIGNATURE-
> > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> > >
> > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurMsACgkQHPApP6U8
> > > pFiGARAAk5GnoU7+3tk16yh+cCme1mzPZiEUf0y1uE8CK74zaNB4OXbeF6iuNOEm
> > > 9OP5MV6zyQC/NxI+DSlUzN32ZUEDLKSw7OUcMmhBfrZs690NEChHTJV9p/EpC7NS
> > > 8LwMU/r3MFrvpkaLuPQsq+DbzbNRefh6+eOEhGTT3WtwW6SYtXxNUbBz4WmCSTrz
> > > LHPYGTpUT19CX2BE5sNQeV5F4/ul3fLSMuVp4RryVo4BLQKBwh/rexb1fUbsdxyn
> > > /v3HyCgreuhFV7DVMF+BuA46sccOm6kScMf7r9LrDioMswZvn79dFGgo9qMDgCWE
> > > 37j7Dnv72GdtlkkNAkP9sKm413B4LzAhuL56bAyK+3SRRKuiqDPgq+4tcEOsIb4u
> > > j6j3ZtJbpoojibAuNZWcvR3kjEPfCDUnRa6JSKXu1Y7Bekr3kLYbiGtOVWXi0ozs
> > > 9zzq8D7lqSDD7b0UhuZ22yuR0OBZMlxn0/ELH0GNikyLuwAd3UrrcNXfL7kpl5P9
> > > BFSEnpZ8uD7bhXrkVCBdM+ktXrCYS8StEIFNwXe5WeUbLdXoCDNKvlKgZKq2/IkD
> > > /Zjh44ecYr8TNdfvyNJxL2YGTUZcfwyZETrMX/1ont7VfFU/xHuh1DE6R60vAtfB
> > > 8nEsqNc+FFocsKlEwQbVyt0XP54DPfPGzXX544NLfbaIr2/2JOk=
> > > =Bjfw
> > > -END PGP SIGNATURE-
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> >
>
>
> --
>
> "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
>
> - Samuel Beckett
>

Re: SSL on Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Luis,

On 10/1/18 11:06 AM, Luis Rodríguez Fernández wrote:
> Agree with Christopher, you have to fix your client. Just get the
> root Certificate Authority public key and import it in your client
> truststore.

I'd recommend trusting the finest-grained cert you can get away with.
That might not always be the root CA cert. It might be the server's
cert directly.

> If you did not change it the client (java) the default keystore is
> located in  $JAVA_HOME/jre/lib/security/cacerts. Something like:
> 
> keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts
> -storepass trust_store_password_here -alias Root -import -file
> the_downloaded_ca.crt
> 
> The default password for cacerts is changeit

FWIW, I wouldn't recommend changing the JVM's trust store. I say so
for two reasons:

1. You will be trusting that certificate for ALL JVMS LAUNCHED
AFTERWARD. Perhaps you don't want some other service to trust your
192.168.1.120 certificate when it's only supposed to be used with a
single client service.

2. You will have to remember to update the trust store every time you
change your Java installation. That means upgrades, downgrades, etc.

The best way to do this IMO is to create a trust store specific for
that service (client) and use it EXPLICITLY.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluyafIACgkQHPApP6U8
pFijGRAAr8BXcoObcsRM/n++276xFYoAJPGKigExp6wpLjI0iHasPpXC0BPaMInb
w7ZkgwAY77Qq7jCcUB8FGrBQXo+axN2r8MVsghV/UyTIwnZyKDM0lb4z6d6016Bc
fQjoalUal857FH20PRAv5U+GrrpNcE7Mua5yu6eTqlMpX2hC0kBCc+oaH6xmtZr/
lvtn9UK5/ymS83yW5sxxYRa3uEnFf6U2EFJoWKGraEOHquEiX01Jn5nOYxccyPMT
TtjZ+yzkc/gvBTsme0ZVdOXTK9m+0Q10f/Fgc4bidSb9ZybaBcm8YsOqpqjP9poC
YU4KtJP7BsJbMVzNV7YFlmIDlOVXwzk84oqEj8trbUe8AtJnq9gCLFp6/1ElmXE4
xP26Gw1ck2vqQC/4u43HsiBegLFaBUorjNw3fWkf3PTiqSXHjXToJK9oYRv1DNkr
SV8dlnujLbqmDQWag2FHTkE6Ka5sFBdbeFUdFP0Qd7jkhmErr5nziO1RtZ1bkIUz
MaCYdpLR+OdU1XMrENnLHRedmpjDXp4UA1/mqr/PSMadQrlK7Z4fF5UVurXFWn7Z
C+HNYzoSmvUL+y1KsficoK3ZGthUpkgApFFbFh3aSKdm07V+Xt1KK6sRndcjdoff
KtU/sG0d0SSLnJmRCJHINRSOccmHZUiWGJ9+UXXE2Gd4nEw43r4=
=okQm
-END PGP SIGNATURE-

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

Re: SSL on Tomcat

[Luis Rodríguez Fernández]

Hello Loai,

Agree with Christopher, you have to fix your client. Just get the root
Certificate Authority public key and import it in your client truststore.
If you did not change it the client (java) the default keystore is located
in  $JAVA_HOME/jre/lib/security/cacerts. Something like:

 keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass
trust_store_password_here -alias Root -import -file the_downloaded_ca.crt

The default password for cacerts is changeit

Hopeit helps,

Luis




El sáb., 29 sept. 2018 a las 12:05, Loai Abdallatif (<
loai.abdalla...@gmail.com>) escribió:

> Thanks Chris, but how to do it, should I copy the ssl certificate from
> Webserver 192.168.1.120 to my tomcat container (worker0) in 192.168.1.111
> in server.xml .
> any idea please
>
> On Sat, Sep 29, 2018 at 1:35 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Loai,
> >
> > On 9/27/18 10:50, Loai Abdallatif wrote:
> > > Hello,
> > >
> > > I have Set Apache Load Balancer ( ModJK) with Server IP
> > > 192.168.1.120 (Webserver01.epsilon.test)  which forward the traffic
> > > to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
> > >
> > > each tomcat server has three workers ( 0,1,2)
> > >
> > > I deployed *Central Authentication Service* (CAS)  on Worker0  and
> > > its is working with warning related to ssl Certificate, I have
> > > another Application on this worker0 called ServiceCatalog
> > > unfortunatly it didnt work and gave error as below
> > >
> > >
> > > ERROR org.jasig.cas.client.util.CommonUtils -
> > > sun.security.validator.ValidatorException: PKIX path building
> > > failed
> > >  : sun.security.provider.certpath.SunCertPathBuilderException:
> > > unable to find valid certification path to requested
> > >  target javax.net.ssl.SSLHandshakeException:
> > > sun.security.validator.ValidatorException: PKIX path building
> > > failed: sun.sec
> > >  urity.provider.certpath.SunCertPathBuilderException: unable to
> > > find valid certification path to requested target
> >
> > As Guido says, your client (org.jasig.cas.client) does not trust the
> > server it's trying to connect to.
> >
> > Is the server in this case the one you set up above? It's not clear
> > exactly what you are trying to do.
> >
> > There is nothing you can change with Tomcat to fix this error... you
> > must configure your client to trust the server.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurMsACgkQHPApP6U8
> > pFiGARAAk5GnoU7+3tk16yh+cCme1mzPZiEUf0y1uE8CK74zaNB4OXbeF6iuNOEm
> > 9OP5MV6zyQC/NxI+DSlUzN32ZUEDLKSw7OUcMmhBfrZs690NEChHTJV9p/EpC7NS
> > 8LwMU/r3MFrvpkaLuPQsq+DbzbNRefh6+eOEhGTT3WtwW6SYtXxNUbBz4WmCSTrz
> > LHPYGTpUT19CX2BE5sNQeV5F4/ul3fLSMuVp4RryVo4BLQKBwh/rexb1fUbsdxyn
> > /v3HyCgreuhFV7DVMF+BuA46sccOm6kScMf7r9LrDioMswZvn79dFGgo9qMDgCWE
> > 37j7Dnv72GdtlkkNAkP9sKm413B4LzAhuL56bAyK+3SRRKuiqDPgq+4tcEOsIb4u
> > j6j3ZtJbpoojibAuNZWcvR3kjEPfCDUnRa6JSKXu1Y7Bekr3kLYbiGtOVWXi0ozs
> > 9zzq8D7lqSDD7b0UhuZ22yuR0OBZMlxn0/ELH0GNikyLuwAd3UrrcNXfL7kpl5P9
> > BFSEnpZ8uD7bhXrkVCBdM+ktXrCYS8StEIFNwXe5WeUbLdXoCDNKvlKgZKq2/IkD
> > /Zjh44ecYr8TNdfvyNJxL2YGTUZcfwyZETrMX/1ont7VfFU/xHuh1DE6R60vAtfB
> > 8nEsqNc+FFocsKlEwQbVyt0XP54DPfPGzXX544NLfbaIr2/2JOk=
> > =Bjfw
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>


-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Re: SSL on Tomcat

[Loai Abdallatif]

Thanks Chris, but how to do it, should I copy the ssl certificate from
Webserver 192.168.1.120 to my tomcat container (worker0) in 192.168.1.111
in server.xml .
any idea please

On Sat, Sep 29, 2018 at 1:35 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Loai,
>
> On 9/27/18 10:50, Loai Abdallatif wrote:
> > Hello,
> >
> > I have Set Apache Load Balancer ( ModJK) with Server IP
> > 192.168.1.120 (Webserver01.epsilon.test)  which forward the traffic
> > to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
> >
> > each tomcat server has three workers ( 0,1,2)
> >
> > I deployed *Central Authentication Service* (CAS)  on Worker0  and
> > its is working with warning related to ssl Certificate, I have
> > another Application on this worker0 called ServiceCatalog
> > unfortunatly it didnt work and gave error as below
> >
> >
> > ERROR org.jasig.cas.client.util.CommonUtils -
> > sun.security.validator.ValidatorException: PKIX path building
> > failed
> >  : sun.security.provider.certpath.SunCertPathBuilderException:
> > unable to find valid certification path to requested
> >  target javax.net.ssl.SSLHandshakeException:
> > sun.security.validator.ValidatorException: PKIX path building
> > failed: sun.sec
> >  urity.provider.certpath.SunCertPathBuilderException: unable to
> > find valid certification path to requested target
>
> As Guido says, your client (org.jasig.cas.client) does not trust the
> server it's trying to connect to.
>
> Is the server in this case the one you set up above? It's not clear
> exactly what you are trying to do.
>
> There is nothing you can change with Tomcat to fix this error... you
> must configure your client to trust the server.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurMsACgkQHPApP6U8
> pFiGARAAk5GnoU7+3tk16yh+cCme1mzPZiEUf0y1uE8CK74zaNB4OXbeF6iuNOEm
> 9OP5MV6zyQC/NxI+DSlUzN32ZUEDLKSw7OUcMmhBfrZs690NEChHTJV9p/EpC7NS
> 8LwMU/r3MFrvpkaLuPQsq+DbzbNRefh6+eOEhGTT3WtwW6SYtXxNUbBz4WmCSTrz
> LHPYGTpUT19CX2BE5sNQeV5F4/ul3fLSMuVp4RryVo4BLQKBwh/rexb1fUbsdxyn
> /v3HyCgreuhFV7DVMF+BuA46sccOm6kScMf7r9LrDioMswZvn79dFGgo9qMDgCWE
> 37j7Dnv72GdtlkkNAkP9sKm413B4LzAhuL56bAyK+3SRRKuiqDPgq+4tcEOsIb4u
> j6j3ZtJbpoojibAuNZWcvR3kjEPfCDUnRa6JSKXu1Y7Bekr3kLYbiGtOVWXi0ozs
> 9zzq8D7lqSDD7b0UhuZ22yuR0OBZMlxn0/ELH0GNikyLuwAd3UrrcNXfL7kpl5P9
> BFSEnpZ8uD7bhXrkVCBdM+ktXrCYS8StEIFNwXe5WeUbLdXoCDNKvlKgZKq2/IkD
> /Zjh44ecYr8TNdfvyNJxL2YGTUZcfwyZETrMX/1ont7VfFU/xHuh1DE6R60vAtfB
> 8nEsqNc+FFocsKlEwQbVyt0XP54DPfPGzXX544NLfbaIr2/2JOk=
> =Bjfw
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: SSL on Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Loai,

On 9/27/18 10:50, Loai Abdallatif wrote:
> Hello,
> 
> I have Set Apache Load Balancer ( ModJK) with Server IP
> 192.168.1.120 (Webserver01.epsilon.test)  which forward the traffic
> to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
> 
> each tomcat server has three workers ( 0,1,2)
> 
> I deployed *Central Authentication Service* (CAS)  on Worker0  and
> its is working with warning related to ssl Certificate, I have
> another Application on this worker0 called ServiceCatalog
> unfortunatly it didnt work and gave error as below
> 
> 
> ERROR org.jasig.cas.client.util.CommonUtils - 
> sun.security.validator.ValidatorException: PKIX path building 
> failed
>  : sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested
>  target javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building
> failed: sun.sec
>  urity.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target

As Guido says, your client (org.jasig.cas.client) does not trust the
server it's trying to connect to.

Is the server in this case the one you set up above? It's not clear
exactly what you are trying to do.

There is nothing you can change with Tomcat to fix this error... you
must configure your client to trust the server.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurMsACgkQHPApP6U8
pFiGARAAk5GnoU7+3tk16yh+cCme1mzPZiEUf0y1uE8CK74zaNB4OXbeF6iuNOEm
9OP5MV6zyQC/NxI+DSlUzN32ZUEDLKSw7OUcMmhBfrZs690NEChHTJV9p/EpC7NS
8LwMU/r3MFrvpkaLuPQsq+DbzbNRefh6+eOEhGTT3WtwW6SYtXxNUbBz4WmCSTrz
LHPYGTpUT19CX2BE5sNQeV5F4/ul3fLSMuVp4RryVo4BLQKBwh/rexb1fUbsdxyn
/v3HyCgreuhFV7DVMF+BuA46sccOm6kScMf7r9LrDioMswZvn79dFGgo9qMDgCWE
37j7Dnv72GdtlkkNAkP9sKm413B4LzAhuL56bAyK+3SRRKuiqDPgq+4tcEOsIb4u
j6j3ZtJbpoojibAuNZWcvR3kjEPfCDUnRa6JSKXu1Y7Bekr3kLYbiGtOVWXi0ozs
9zzq8D7lqSDD7b0UhuZ22yuR0OBZMlxn0/ELH0GNikyLuwAd3UrrcNXfL7kpl5P9
BFSEnpZ8uD7bhXrkVCBdM+ktXrCYS8StEIFNwXe5WeUbLdXoCDNKvlKgZKq2/IkD
/Zjh44ecYr8TNdfvyNJxL2YGTUZcfwyZETrMX/1ont7VfFU/xHuh1DE6R60vAtfB
8nEsqNc+FFocsKlEwQbVyt0XP54DPfPGzXX544NLfbaIr2/2JOk=
=Bjfw
-END PGP SIGNATURE-

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

Re: SSL on Tomcat

[Loai Abdallatif]

Thank you Guido

appreciate your assistance , and if possible send me any tutorial related
to my case ( apache server different than Tomcat , CAS app need SSL )

On Fri, Sep 28, 2018 at 11:40 AM Jäkel, Guido  wrote:

> Dear Loai,
>
> Your client can't very (don't trust) the certificate (chain) of the
> target. Either target's certificate is not an "official" one (e.g. self
> signed) or your clients JVM certificate trust chain is not up to date.
>
> I you like I may send you a small java commandline tool to check the
> verification chain and/or add exceptions to the local trust store in case
> of self-signed certificates.
>
> Guido
>
>
> >-Original Message-
> >From: Loai Abdallatif [mailto:loai.abdalla...@gmail.com]
> >Sent: Thursday, September 27, 2018 4:52 PM
> >To: Tomcat Users List 
> >Subject: Re: SSL on Tomcat
> >
> >hello, shall I add the certificate to server.xml on tomcat server or just
> on Webserver
> >
> >
> >On Thu, Sep 27, 2018 at 5:50 PM, Loai Abdallatif <
> loai.abdalla...@gmail.com <mailto:loai.abdalla...@gmail.com> > wrote:
> >
> >
> >   Hello,
> >
> >   I have Set Apache Load Balancer ( ModJK) with Server IP
> 192.168.1.120 (Webserver01.epsilon.test)  which forward the
> >traffic to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
> >
> >
> >   each tomcat server has three workers ( 0,1,2)
> >
> >   I deployed Central Authentication Service (CAS)  on Worker0  and
> its  is working with warning related to ssl
> >Certificate, I have another Application on this worker0 called
> ServiceCatalog unfortunatly it didnt work and gave error as below
> >
> >
> >
> >
> >
> >
> >
> >
> >   ERROR org.jasig.cas.client.util.CommonUtils -
> sun.security.validator.ValidatorException: PKIX path building failed
> >: sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested
> >target
> >   javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.sec
> >urity.provider.certpath.SunCertPathBuilderException: unable to find valid
> certification path to requested target
> >   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> >   at
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
> >   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
> >   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
> >   at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
> >   at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> >   at
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> >   at
> sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> >   at
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
> >   at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
> >   at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
> >   at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
> >   at
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
> >   at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnectio
> >n.java:185)
> >   at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
> >   at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
> >   at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
> >   at
> org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:429)
> >   at
> org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTicketValidator.retrieveResponseFromServer(A
> >bstractCasProtocolUrlBasedTicketValidator.java:41)
> >   at
> org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidato
> >r.java:193)
> >   at
> org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticateNow(CasAuthentica
> >tionProvider.java:157)
> >   at
> org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticate(CasAuthenticatio
> >nProvider.java:142)
> >
> >
> >
>
>

RE: SSL on Tomcat

[Jäkel , Guido]

Dear Loai,

Your client can't very (don't trust) the certificate (chain) of the target. 
Either target's certificate is not an "official" one (e.g. self signed) or your 
clients JVM certificate trust chain is not up to date.

I you like I may send you a small java commandline tool to check the 
verification chain and/or add exceptions to the local trust store in case of 
self-signed certificates.

Guido


>-Original Message-
>From: Loai Abdallatif [mailto:loai.abdalla...@gmail.com]
>Sent: Thursday, September 27, 2018 4:52 PM
>To: Tomcat Users List 
>Subject: Re: SSL on Tomcat
>
>hello, shall I add the certificate to server.xml on tomcat server or just on 
>Webserver
>
>
>On Thu, Sep 27, 2018 at 5:50 PM, Loai Abdallatif <mailto:loai.abdalla...@gmail.com> > wrote:
>
>
>   Hello,
>
>   I have Set Apache Load Balancer ( ModJK) with Server IP 192.168.1.120 
> (Webserver01.epsilon.test)  which forward the
>traffic to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
>
>
>   each tomcat server has three workers ( 0,1,2)
>
>   I deployed Central Authentication Service (CAS)  on Worker0  and its  
> is working with warning related to ssl
>Certificate, I have another Application on this worker0 called ServiceCatalog 
>unfortunatly it didnt work and gave error as below
>
>
>
>
>
>
>
>
>   ERROR org.jasig.cas.client.util.CommonUtils - 
> sun.security.validator.ValidatorException: PKIX path building failed
>: sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>valid certification path to requested
>target
>   javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: sun.sec
>urity.provider.certpath.SunCertPathBuilderException: unable to find valid 
>certification path to requested target
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>   at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
>   at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
>   at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
>   at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
>   at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
>   at 
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
>   at 
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnectio
>n.java:185)
>   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
>   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
>   at 
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
>   at 
> org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:429)
>   at 
> org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTicketValidator.retrieveResponseFromServer(A
>bstractCasProtocolUrlBasedTicketValidator.java:41)
>   at 
> org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidato
>r.java:193)
>   at 
> org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticateNow(CasAuthentica
>tionProvider.java:157)
>   at 
> org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticate(CasAuthenticatio
>nProvider.java:142)
>
>
>

Re: SSL on Tomcat

[Loai Abdallatif]

hello, shall I add the certificate to server.xml on tomcat server or just
on Webserver

On Thu, Sep 27, 2018 at 5:50 PM, Loai Abdallatif 
wrote:

> Hello,
>
> I have Set Apache Load Balancer ( ModJK) with Server IP 192.168.1.120
> (Webserver01.epsilon.test)  which forward the traffic to tomcat server
> .(192.168.1.111 (appserver01.epsilon.test)
>
> each tomcat server has three workers ( 0,1,2)
>
> I deployed *Central Authentication Service* (CAS)  on Worker0  and its
> is working with warning related to ssl Certificate, I have another
> Application on this worker0 called ServiceCatalog unfortunatly it didnt
> work and gave error as below
>
>
>
>
>
>
> ERROR org.jasig.cas.client.util.CommonUtils - 
> sun.security.validator.ValidatorException:
> PKIX path building failed
>
>: 
> sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested
>
>target
> javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException:
> PKIX path building failed: sun.sec
>
> 
> urity.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
> at sun.security.ssl.ClientHandshaker.serverCertificate(
> ClientHandshaker.java:1614)
> at sun.security.ssl.ClientHandshaker.processMessage(
> ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> at sun.security.ssl.SSLSocketImpl.readRecord(
> SSLSocketImpl.java:1072)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(
> SSLSocketImpl.java:1385)
> at sun.security.ssl.SSLSocketImpl.startHandshake(
> SSLSocketImpl.java:1413)
> at sun.security.ssl.SSLSocketImpl.startHandshake(
> SSLSocketImpl.java:1397)
> at sun.net.www.protocol.https.HttpsClient.afterConnect(
> HttpsClient.java:559)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnec
> tion.connect(AbstractDelegateHttpsURLConnectio
>
> n.java:185)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(
> HttpURLConnection.java:1564)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(
> HttpURLConnection.java:1492)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.
> getInputStream(HttpsURLConnectionImpl.java:263)
> at org.jasig.cas.client.util.CommonUtils.getResponseFromServer(
> CommonUtils.java:429)
> at org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTic
> ketValidator.retrieveResponseFromServer(A
>
> bstractCasProtocolUrlBasedTicketValidator.java:41)
> at org.jasig.cas.client.validation.AbstractUrlBasedTicketValidato
> r.validate(AbstractUrlBasedTicketValidato
>
>  r.java:193)
> at org.springframework.security.cas.authentication.
> CasAuthenticationProvider.authenticateNow(CasAuthentica
>
>
> tionProvider.java:157)
> at org.springframework.security.cas.authentication.
> CasAuthenticationProvider.authenticate(CasAuthenticatio
>
>
> nProvider.java:142)
>
>

Re: SSL Encryption for Cluster Conversations (NioReceiver and Members)

[Mark Thomas]

On 14/09/2018 16:01, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/14/18 08:34, Mark Thomas wrote:

On 14/09/18 13:11, Tim K wrote:

Using latest Tomcat 9.0.11.  I'm using the securePort attribute
for both the NioReceiver and StaticMembers but when capturing and
inspecting the traffic over the secure ports with WireShark, I'm
seeing all my session data in clear text, even my username as
password (user principal)!  I tried removing the port attribute
from both, elements, leaving just the securePort there but this
does not encrypt the traffic.


To my knowledge, the port was added but TLS was never implemented.
It may be better if we remove that code entirely. Why you'd want a
secure port and an insecure port at the same time for a cluster
never did make much sense to me.

The typical TLS configuration is a poor choice for clusters It
would require quite a lot of configuration. Encryption based on a
pre-shared private key would be a better approach.


Why?


Long (and bitter) experience tells me that most folks have a hard time 
setting up TLS so it works. Generating a single file (for the shared 
secret - which we can easily provide a script to generate) and copying 
that one file to multiple machines is a much simpler process.



Each server with a server-cert and each client with a bag of
trusted certs doesn't seem that big of a deal. Even
mutual-authentication just adds another bag of trust on each server
and a client-cert on each client. If you set up a private signing
authority, it gets even easier.

But I agree, there shouldn't be two ports to configure. Just one, and
if we decide to add encryption, you should just be able to say "yes,
please" and have it work over the same port... assuming all nodes are
configured the same, of course.

Applying encryption shouldn't be too hard, code-wise, if all we wanted
to do was encrypt each message going over the (otherwise plaintext)
wire. Each node needs to know the encryption flavor in use (cipher,
padding, etc.) and a pre-shared key. That's just two configuration
elements in server.xml and one of them (the cipher) can default to
something reasonable such as AES/CBC/PKCS5Padding.

This would be a good Google Summer of Code project, though it wouldn't
actually take that long. Maybe Google Midsummer of Code :)


Worth adding a BZ enhancement for this.

Mark




- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubzUkACgkQHPApP6U8
pFi8Sw/+McP0UxnqhcWKe+ErhWXX/AmiMdsvx1URDIw3GGec0P6p7zyIDldllnjr
/nbXDmYTRX3SUcXAd80h0p86HG44G0NKtRkzMwCbdUkKLtwHxASsYAnuzMSL7Xaf
Vh+ohgEfqjDurcor+xJZRFPweCFn+a7ID41jv5i42oYr0QC4o1xBCPzXYNcb6UnP
JYGBuxOVthaHnEBcGej3sQCNMNWQvoyQphvsprXUkHMjXZt3/esTRe0Nj0d9O+sQ
AEGli/gN4UQeIPU0yU1nZXyrKuHE/qupU4TLkIDlFE36XHMY8SHX3bEnVD23fEkk
goftmlsefu+SyXlemO0q9h2X/eL2GFKFJn0ALQUb4u354QKpyDYh4FTK8VJnnN/2
lOVjbCfq39gBnZ4wZntJUVN+4BB2elQs4PrLOrDAwrZYCNzvKgfmI6V0xEQCTrfO
7tiJ+YJnIgUuFqyfKi5b4RnvZC5LasZ0Uw/nWjlHyVd5xwrRgspdEDRRKapsnzb8
3y7vle6UM/nOdmbQ99cnERtQ8qdmiy6FGnaVm8Gt96Se4Gj3SlpwfHx1tO+py5Us
Gc3sxDiXzlhs79CqYwqJDaAzK5iQfATVUKJ1f8GT+Zc6RGbIUL/ERkTrJhDD0rbL
eZSSKArJj6DwzkjS8CjapJGs/UhmeShb0wX29KLploEofVqfRIc=
=JMu5
-END PGP SIGNATURE-

-
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

Re: SSL Encryption for Cluster Conversations (NioReceiver and Members)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/14/18 08:34, Mark Thomas wrote:
> On 14/09/18 13:11, Tim K wrote:
>> Using latest Tomcat 9.0.11.  I'm using the securePort attribute
>> for both the NioReceiver and StaticMembers but when capturing and
>> inspecting the traffic over the secure ports with WireShark, I'm
>> seeing all my session data in clear text, even my username as
>> password (user principal)!  I tried removing the port attribute
>> from both, elements, leaving just the securePort there but this
>> does not encrypt the traffic.
> 
> To my knowledge, the port was added but TLS was never implemented.
> It may be better if we remove that code entirely. Why you'd want a
> secure port and an insecure port at the same time for a cluster
> never did make much sense to me.
> 
> The typical TLS configuration is a poor choice for clusters It
> would require quite a lot of configuration. Encryption based on a
> pre-shared private key would be a better approach.

Why? Each server with a server-cert and each client with a bag of
trusted certs doesn't seem that big of a deal. Even
mutual-authentication just adds another bag of trust on each server
and a client-cert on each client. If you set up a private signing
authority, it gets even easier.

But I agree, there shouldn't be two ports to configure. Just one, and
if we decide to add encryption, you should just be able to say "yes,
please" and have it work over the same port... assuming all nodes are
configured the same, of course.

Applying encryption shouldn't be too hard, code-wise, if all we wanted
to do was encrypt each message going over the (otherwise plaintext)
wire. Each node needs to know the encryption flavor in use (cipher,
padding, etc.) and a pre-shared key. That's just two configuration
elements in server.xml and one of them (the cipher) can default to
something reasonable such as AES/CBC/PKCS5Padding.

This would be a good Google Summer of Code project, though it wouldn't
actually take that long. Maybe Google Midsummer of Code :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubzUkACgkQHPApP6U8
pFi8Sw/+McP0UxnqhcWKe+ErhWXX/AmiMdsvx1URDIw3GGec0P6p7zyIDldllnjr
/nbXDmYTRX3SUcXAd80h0p86HG44G0NKtRkzMwCbdUkKLtwHxASsYAnuzMSL7Xaf
Vh+ohgEfqjDurcor+xJZRFPweCFn+a7ID41jv5i42oYr0QC4o1xBCPzXYNcb6UnP
JYGBuxOVthaHnEBcGej3sQCNMNWQvoyQphvsprXUkHMjXZt3/esTRe0Nj0d9O+sQ
AEGli/gN4UQeIPU0yU1nZXyrKuHE/qupU4TLkIDlFE36XHMY8SHX3bEnVD23fEkk
goftmlsefu+SyXlemO0q9h2X/eL2GFKFJn0ALQUb4u354QKpyDYh4FTK8VJnnN/2
lOVjbCfq39gBnZ4wZntJUVN+4BB2elQs4PrLOrDAwrZYCNzvKgfmI6V0xEQCTrfO
7tiJ+YJnIgUuFqyfKi5b4RnvZC5LasZ0Uw/nWjlHyVd5xwrRgspdEDRRKapsnzb8
3y7vle6UM/nOdmbQ99cnERtQ8qdmiy6FGnaVm8Gt96Se4Gj3SlpwfHx1tO+py5Us
Gc3sxDiXzlhs79CqYwqJDaAzK5iQfATVUKJ1f8GT+Zc6RGbIUL/ERkTrJhDD0rbL
eZSSKArJj6DwzkjS8CjapJGs/UhmeShb0wX29KLploEofVqfRIc=
=JMu5
-END PGP SIGNATURE-

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

Re: SSL Encryption for Cluster Conversations (NioReceiver and Members)

[Mark Thomas]

On 14/09/18 13:11, Tim K wrote:
> Using latest Tomcat 9.0.11.  I'm using the securePort attribute for both
> the NioReceiver and StaticMembers but when capturing and inspecting the
> traffic over the secure ports with WireShark, I'm seeing all my session
> data in clear text, even my username as password (user principal)!  I tried
> removing the port attribute from both, elements, leaving just the
> securePort there but this does not encrypt the traffic.

To my knowledge, the port was added but TLS was never implemented. It
may be better if we remove that code entirely. Why you'd want a secure
port and an insecure port at the same time for a cluster never did make
much sense to me.

The typical TLS configuration is a poor choice for clusters It would
require quite a lot of configuration. Encryption based on a pre-shared
private key would be a better approach.

Mark

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

Re: SSL Certificates and Tomcat 8.5.11

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurie,

On 5/17/18 11:33 AM, Laurie Miller-Cook wrote:
> I am very new to Tomcat so please bear with me.

Welcome.

> I currently have a Thawte certificate that is installed within IIS 
> for our domain that is all managed by Rackspace.
> 
> I now have a new server set-up with Tomcat 8.5.11 installed and
> have created a keystore.
> 
> I have been supplied by Rackspace the following text a
> Certificate, Private Key and CA Bundle.

You should start over. If Rackspace supplied the private key, then you
have no control over your own security. You should generate your own
private key on a server you control and trust.

> So my question is, with the three text files from Rackspace can I 
> import these (in what order) into the Keystore to get SSL working 
> with our Domain or do I need something totally different.
> 
> Just as a sub-note we need to have the SSL certificate for the
> domain working on both IIS and Tomcat.

It is very difficult to import a private key into a Java keystore. You
usually have to go through a PKCS12 file, first, and OpenSSL is the
best tool IMO to manipulate those. JKS files are fortunately being
abandoned and PKCS12 files are directly-readable by Java, so it's a
one-step operation if you have OpenSSL handy:

openssl pkcs12 -export -in server.crt -inkey server.key -certfile
intermediate.crt -out keystore.p12 -chain

Now, you can configure your Tomcat to use keystore.p12 as the
keystore, and use whatever password you gave to OpenSSL when writing
the PKCS12 file.

I'd still highly recommend that you start over from scratch with
yourown private key, though. Generate a key, certificate signing
request (CSR), and send the CSR to Thawte. Once they sign it, import
any intermediate certs into your keystore first (top-most first) then
your server's signed certificate into your keystore and use the result
with Tomcat.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlr95eYACgkQHPApP6U8
pFj3PRAAlEHlY5czP+i7yHyqgWakieUufMJDcW98JpEZdq9fiv+fTtSKQzx0IKOV
Z588ikrZU7DdRhB5WNMiYFO9fDMtiV5d7KhGEBggSzuyAKEFDos1YXpk2uj42lPH
u3OSXS4igkgbWWiuxRxjSNlyMpTHoG+TSdhr7+W/hdF2rMnHSBz4VgEteQVymXeu
pHyjTeIp2CabKYmz9u2A86vF2pdmwLUQ2B4twvRkdCG6QNcr8uOom70itltvXGIG
T7vhtFgjYnJQ0MqV1+QJbBEfO0NVIE/+LKseuiGoGJN5oWWQY8MdW5yfH2mQcITk
bCAkDUkbBHTBnWgAl3U6Ly/k7mtfRa2FQfPOpPVyoefMgpwJGYPQ0U7IPr6YIROw
X6Rc/9FTerAmkwUgv9Ls2Hsyi31J5BqS1dhp4+kEYWoGEMq+Uu0Cy8GJqPvPJM75
sug6rQuLSaARB2b1inNkvwED3u2ju6HVCgp+5M4hyHDkLuYPajpRau+LC1gusHeN
UB/zaLLUZZL1Ujr9WvDHnEFSBj+UmpUCwLRiqeUZKIlX/JdmBZA2nlxdbMgBWztq
GPkdvhKCEO2SGJi1q5OJ6NiNtC4H93ZmNvbg1xtQGweRjmc8LfLIjgEiMAsCA2ns
7Wjr8lMO93t4ehWnmDQYk34uHL6I9ieWDfFkvmN2DD+SPsL9ibU=
=154L
-END PGP SIGNATURE-

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

Re: SSL Certificates and Tomcat 8.5.11

[Pierre Chiu]

Hi Laurie,

This is what I do. I don't use keystore.

I use this within SSLHostConfig section.





> On May 17, 2018, at 11:33 AM, Laurie Miller-Cook 
>  wrote:
> 
> Hi there,
> 
> I am very new to Tomcat so please bear with me.
> 
> I currently have a Thawte certificate that is installed within IIS for our 
> domain that is all managed by Rackspace.
> 
> I now have a new server set-up with Tomcat 8.5.11 installed and have created 
> a keystore.
> 
> I have been supplied by Rackspace the following text a Certificate, Private 
> Key and CA Bundle.
> 
> So my question is, with the three text files from Rackspace can I import 
> these (in what order) into the Keystore to get SSL working with our Domain or 
> do I need something totally different.
> 
> Just as a sub-note we need to have the SSL certificate for the domain working 
> on both IIS and Tomcat.
> 
> Best regards
> 
> Laurie


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

Re: SSL and IPv6 when using address to set a specific IP

[Rick Trudeau]

On Mon, Mar 5, 2018 at 10:35 AM, Mark Thomas  wrote:
> On 05/03/18 15:00, Mark Thomas wrote:
>> On 05/03/18 02:02, Rick Trudeau wrote:
>>> Hi,
>>> I'm having some problems using SSL on my connector when binding it to
>>> a specific IPv6 address.
>>> I'm trying this on Tomcat v 8.5.28, Ubuntu 14.04, JVM v1.8.0_161-b12.
>
> 
>
>>> 05-Mar-2018 01:11:11.724 WARNING [main]
>>> org.apache.tomcat.util.net.AbstractEndpoint.registerJmx Unable to
>>> generate a valid JMX object name for the SSLHostConfig associated
>>> withhost [_default_]
>>>  javax.management.MalformedObjectNameException: Invalid character ':'
>>> in value part of property
>
> 
>
>>> Has anyone had any success binding to a specific IPv6 literal address
>>> when using SSL?
>>
>> Ah. That looks like a bug generating the MBean name from the address
>> attribute. Let me take a look.
>
> The good news is that that error shouldn't stop the TLS connector
> working although it won't be exposed via JMX.
>
> I've fixed this but unfortunately the next set of releases were tagged
> this morning so the fix won't be available until 9.0.7 / 8.5.30 which -
> unless the current releases fail for some reason - most likely won't be
> available until early next month.
>
> Mark
>


Well that's certainly a quick turnaround!
Thanks for you help with this Mark, we'll keep our eyes open for 8.5.30.

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

Re: SSL and IPv6 when using address to set a specific IP

[Mark Thomas]

On 05/03/18 15:00, Mark Thomas wrote:
> On 05/03/18 02:02, Rick Trudeau wrote:
>> Hi,
>> I'm having some problems using SSL on my connector when binding it to
>> a specific IPv6 address.
>> I'm trying this on Tomcat v 8.5.28, Ubuntu 14.04, JVM v1.8.0_161-b12.



>> 05-Mar-2018 01:11:11.724 WARNING [main]
>> org.apache.tomcat.util.net.AbstractEndpoint.registerJmx Unable to
>> generate a valid JMX object name for the SSLHostConfig associated
>> withhost [_default_]
>>  javax.management.MalformedObjectNameException: Invalid character ':'
>> in value part of property



>> Has anyone had any success binding to a specific IPv6 literal address
>> when using SSL?
> 
> Ah. That looks like a bug generating the MBean name from the address
> attribute. Let me take a look.

The good news is that that error shouldn't stop the TLS connector
working although it won't be exposed via JMX.

I've fixed this but unfortunately the next set of releases were tagged
this morning so the fix won't be available until 9.0.7 / 8.5.30 which -
unless the current releases fail for some reason - most likely won't be
available until early next month.

Mark

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

Re: SSL and IPv6 when using address to set a specific IP

[Mark Thomas]

On 05/03/18 02:02, Rick Trudeau wrote:
> Hi,
> I'm having some problems using SSL on my connector when binding it to
> a specific IPv6 address.
> I'm trying this on Tomcat v 8.5.28, Ubuntu 14.04, JVM v1.8.0_161-b12.
> 
> My connector config looks like this:
> maxThreads="150"
>scheme="https"
>secure="true"
>SSLEnabled="true"
>keystoreFile="/opt/keystore/keystore"
>keystorePass="secret"
>clientAuth="false"
>keyAlias="myAlias"
>sslProtocol="TLS"
>address="fe80::a00:27ff:fe13:ca0d"/>
> 
> catalina.out shows this exception immediately after startup.  I think
> it indicates there are some parsing errors when parsing the IPv6
> address.
> 
> 05-Mar-2018 01:11:11.141 INFO [main]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["https-jsse-nio-fe80:0:0:0:a00:27ff:fe13:ca0d-8443"]
> 05-Mar-2018 01:11:11.709 INFO
> [main]org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector
> Using a shared selector for servlet write/read
> 05-Mar-2018 01:11:11.724 WARNING [main]
> org.apache.tomcat.util.net.AbstractEndpoint.registerJmx Unable to
> generate a valid JMX object name for the SSLHostConfig associated
> withhost [_default_]
>  javax.management.MalformedObjectNameException: Invalid character ':'
> in value part of property
> at javax.management.ObjectName.construct(ObjectName.java:618)
> at javax.management.ObjectName.(ObjectName.java:1382)
> at 
> org.apache.tomcat.util.net.AbstractEndpoint.registerJmx(AbstractEndpoint.java:1105)
> at 
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1095)
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:268)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
> at 
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
> at 
> org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at 
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at 
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:632)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:655)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> 
> If I remove address attribute to allow binding on all interfaces,
> things are good.  But my use case, however, requires binding to a
> specific IPv6 address.
> Since these SSL attributes are deprecated from what I've read, I've
> also tried moving the SSL configs to the newer SSLHostConfig block,
> but the same error remains.
> 
> Has anyone had any success binding to a specific IPv6 literal address
> when using SSL?

Ah. That looks like a bug generating the MBean name from the address
attribute. Let me take a look.

Mark

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

Re: SSL: Unexpected end of file from server

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alex,

On 3/1/18 9:24 AM, Alex O'Ree wrote:
> I have a CXF web service client accessing a CXF SOAP service
> running in tomcat. I'm seeing intermitent issues only when using
> SSL and I'm not entirely sure why. The client logs the following 
> SocketException: Unexpected end of file from server at
> sun.net.www.http.Client.parseHTTPHeader
> 
> I'm using the default connector that tomcat ships with
> (Http11NioProtocol) on the latest 8.5.28

Can you post your  configuration (minus any secrets) and
the complete stack trace of the SocketException? Is the exception
occurring on the CXF client or server? (Looks like the client, just
double-checking).

> Is there anything I can do on the tomcat side to try and
> troubleshoot this?

Is it reproducible in a lab environment? You might want to enable
trace-level logging for Tomcat, etc.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqYMM0ACgkQHPApP6U8
pFjZvxAAkm5+izmmXyI5Ba2xgNjgcwSNuI/+hB088Mpf0VERPfINK+yBU5YU2RJD
Cr09KTVNW5qf4K7+T2M2PGS38h/XitZ4V2+DvWhyF0vwWXl6195QXMqRhSFXmQAx
d8NYMQFR7q2rPkCc2xN9ZMCJHE8k2j6moFXHhzuJ9hqoLUf066YEfRqN927s2UR+
ltubAl+XwaS8EYK3/hXIGFD8/4wGuF9JxMyAzETTKVCbwfcGysBfElnexMaT2vUi
uf93zHjdhTv4bKbpeGfUem1Wl9J/DgURQ9DGXxLMi0J1R/y38kOZs85B7hoobysv
HCiZ6SQXcya1nxsbGUvLGwB5SPMnnYmm/vpnewO3O0vVUycPRcowGIUhk0S7N5tH
UTuZaf2AENn3TTa9Tfjr/caRg/aqDKEeVDNIhQtCZjujpsqFBVU02r6Fybxu2eWC
lRb1p2t1zCJ62Zpm9dShZJOdIcfc0qbnK6tGVV+gpz1opfCKiffYJCqWCS0LO3mY
4XZ+mrszCk6smu9gAa/qdF7IN5JDu1XpKXIUXH1U43BAzSJN465aMhjkHI2Ij4E9
URyS7OF8BlBxBVbZ5da4YXwHLnBGUucuMBNXX0rt5gbB91oSDcoizGvPXmGMQLSE
zDlx3EJByPa7nBf18JyaaYINNcWQLAY7caoM1LdJtZGK8xP+yo8=
=zZ3i
-END PGP SIGNATURE-

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

Re: SSL connectors

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 12/6/17 7:32 AM, Johan Compagner wrote:
> On 1 December 2017 at 16:44, Mark Thomas  wrote:
> 
>> On 01/12/17 14:57, Chris Cheshire wrote:
>>> I see in the changelog for 8.5.24
>>> 
>>> 60762: Add the ability to make changes to the TLS configuration
>>> of a connector at runtime without having to restart the
>>> Connector. (markt)
>>> 
>>> Does this mean we can now update SSL certificates without
>>> bouncing the connector?
>> 
>> Yes, via one of the following methods on the endpoint:
>> 
>> reloadSslHostConfig(String hostName) reloadSslHostConfigs()
>> 
>> 
>> 
> now it would be nice if tomcat just had a build in file scanner
> that  calls those method for use without doing anything else then
> change the file on disk ;)

This could easily be done using the background processor.

Care to propose a patch?

Be sure to make sure this feature is OPT-IN... it's not okay to
auto-reload a file on the disk if the admin doesn't want that to happen.
..

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlooJkIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiUHRAAgfQf/DyjfF1ocSwW
206zT+eWeKoIE1hYQ+tUsUyFYM+lH3ULKcFjWEMHZ7RNYrRPL6FFAynK9zyaeEoU
QU7ZpSfBI0tlVrKuPboRWFXYib00/tISxEF8yefSCkMsp8L94heTTfj3atiwmWju
fzWVCFzxLX3akZOoQRjjC0Pv5yDivDCF6z/CpYlChGsD2cA/h363X8u8nfW/gCUr
G2O9KlOB0B67uSHWnBMmkSF5f3xHW1bWwq4bfl4LnAafEfO2If9LhURmcb4rAef1
wUt62+aCkvB30HzQPaAV2mct+Ice0M9eAwBIYVZuwBnQWb87CTVd0OQ5MeNmbY6w
bPexKyy5fp37P6gaUMPZeDYpVHi7+XVuNNKHCnFhJclTB45i+yj2BFjNkjtRrPMb
dsO8Sx+Ma0w8xXPcqL9desNsu4yeIY2w7dOLIn5stQrgms5KWOX+xfDlAIQJmgOV
eOBM7BXBv4iErPBzVyCMQrzX0BE9P/Q/+lQonHHQgbWSxIAkDSHx4HPsHIvuY0pH
nzX1mm8gh/BLSCx+8082V+6N6fOQhWBc+Sir2L/0m1KaoojnRKUT167X0LQcnagV
e4aq1csZLed4F/KjiV5QA4b6WMwy3wQjanCUDauxV7YTqXPk9kv9P5FrlpYjv6YD
Nf5ZkjozGyOuTqfICtTqi2sCVBA=
=F0ZN
-END PGP SIGNATURE-

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

Re: SSL connectors

[Johan Compagner]

On 1 December 2017 at 16:44, Mark Thomas  wrote:

> On 01/12/17 14:57, Chris Cheshire wrote:
> > I see in the changelog for 8.5.24
> >
> > 60762: Add the ability to make changes to the TLS configuration of a
> > connector at runtime without having to restart the Connector. (markt)
> >
> > Does this mean we can now update SSL certificates without bouncing the
> > connector?
>
> Yes, via one of the following methods on the endpoint:
>
> reloadSslHostConfig(String hostName)
> reloadSslHostConfigs()
>
>
>
now it would be nice if tomcat just had a build in file scanner that  calls
those method for use without doing anything else then change the file on
disk ;)

Re: SSL connectors

[Mark Thomas]

On 06/12/17 01:06, George S. wrote:
> 
> 
> On 12/1/2017 8:44 AM, Mark Thomas wrote:
>> On 01/12/17 14:57, Chris Cheshire wrote:
>>> I see in the changelog for 8.5.24
>>>
>>> 60762: Add the ability to make changes to the TLS configuration of a
>>> connector at runtime without having to restart the Connector. (markt)
> 
> What strikes me as odd is that SSL Certificates are still coupled to
> connectors. It seems like certificates should be coupled to Hosts since
> that's what SNI does. SNI removes the coupling between an IP and a
> virtual host name.
> 
> Pre-SNI, there was a logical reason to associate a certificate with a
> connector. The fact that you could only have one certificate on one IP,
> made the one-to-one correlation obvious. Now, with SNI, you can have
> many SSL Certificates with one IP. However, Tomcat's continuation of
> associating the SSL Certificate with the Connector, rather than the
> virtual host it's associated with is cumbersome because now when I
> configure a virtual host with an SSL certificate, I not only have to
> configure the host, but also the connector. As a database person, I try
> to follow the rule that the attributes should follow the entity. In this
> case, the attributes (SSLHostConfig) are facts about the virtual host,
> and not about the Connector (entity).
> 
> I'd like to see the Connector iterate over the virtual hosts and pick up
> the SSLHostConfig from there. Perhaps the SSLHostConfig should have an
> optional attribute "ConnectorName" to identify which Connector (assuming
> there are multiple) the SSLHostConfig should bind to for the case of
> multi-homed machines. The "ConnectorName" attribute would be used in
> multi-homed hosts to specify which (of several) connectors the
> SSLHostConfig should bind to.

The relationship between virtual host, SSLHostConfig and Connector is a
complex one. Various options were considered when implementing SNI.

The solution you propose assumes that there is a 1-2-1 mapping between
virtual host and SSLHostConfig. That is not always the case. The use of
wildcard certificates and Subject Alternative Names (SAN) so a
certificate can be used with multiple virtual hosts means that the
mapping can be complex.

The complex mapping, combined with a requirement to provide a smooth
migration path for existing uses led to the current solution.

(Note that we don't currently support multiple aliases for a
SSLHostConfig - that is something that should be fairly easy to add if
required.)

Tweaks to the existing implementation to simplify some use cases are
always possible and - assuming no impact on existing users - likely to
be accepted. The more significant the change, the greater the impact to
existing users and the less likely the change is to be accepted.

> Since I'm on wish lists, I wish that the Host XML snippet could be
> specified via a file in $CATALINA_BASE/conf/EngineName/Virtual.Host.Name
> via a magic name like _HOST.xml, or the like. I run anywhere from
> 600-2000 virtual hosts on a machine, and my current "work-around" is to
> use the inclusion hack to bring in an external file with the defined
> virtual hosts.

Each virtual host with its own set of web applications?

Automatic inclusion of hosts sounds doable but needs thinking through. I
don't see any immediate gotchas but it is similar to automatic context
deployment and there are a huge number of edge cases in that use case
once you start thinking about it. Automatic inclusion at start-up but no
automatic deployment while running would be a lot simpler to implement.

Mark

> 
> 
>>>
>>> Does this mean we can now update SSL certificates without bouncing the
>>> connector?
>> Yes, via one of the following methods on the endpoint:
>>
>> reloadSslHostConfig(String hostName)
>> reloadSslHostConfigs()
>>
>> If accessing this via JMX, they appear as operations on the ThreadPool
>> objects.
>>
>> Mark
>>
>> -
>> 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

Re: SSL connectors

[George S.]

On 12/1/2017 8:44 AM, Mark Thomas wrote:

On 01/12/17 14:57, Chris Cheshire wrote:

I see in the changelog for 8.5.24

60762: Add the ability to make changes to the TLS configuration of a
connector at runtime without having to restart the Connector. (markt)


What strikes me as odd is that SSL Certificates are still coupled to 
connectors. It seems like certificates should be coupled to Hosts since 
that's what SNI does. SNI removes the coupling between an IP and a 
virtual host name.


Pre-SNI, there was a logical reason to associate a certificate with a 
connector. The fact that you could only have one certificate on one IP, 
made the one-to-one correlation obvious. Now, with SNI, you can have 
many SSL Certificates with one IP. However, Tomcat's continuation of 
associating the SSL Certificate with the Connector, rather than the 
virtual host it's associated with is cumbersome because now when I 
configure a virtual host with an SSL certificate, I not only have to 
configure the host, but also the connector. As a database person, I try 
to follow the rule that the attributes should follow the entity. In this 
case, the attributes (SSLHostConfig) are facts about the virtual host, 
and not about the Connector (entity).


I'd like to see the Connector iterate over the virtual hosts and pick up 
the SSLHostConfig from there. Perhaps the SSLHostConfig should have an 
optional attribute "ConnectorName" to identify which Connector (assuming 
there are multiple) the SSLHostConfig should bind to for the case of 
multi-homed machines. The "ConnectorName" attribute would be used in 
multi-homed hosts to specify which (of several) connectors the 
SSLHostConfig should bind to.


Since I'm on wish lists, I wish that the Host XML snippet could be 
specified via a file in $CATALINA_BASE/conf/EngineName/Virtual.Host.Name 
via a magic name like _HOST.xml, or the like. I run anywhere from 
600-2000 virtual hosts on a machine, and my current "work-around" is to 
use the inclusion hack to bring in an external file with the defined 
virtual hosts.





Does this mean we can now update SSL certificates without bouncing the
connector?

Yes, via one of the following methods on the endpoint:

reloadSslHostConfig(String hostName)
reloadSslHostConfigs()

If accessing this via JMX, they appear as operations on the ThreadPool
objects.

Mark

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



--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: SSL connectors

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/1/17 10:44 AM, Mark Thomas wrote:
> On 01/12/17 14:57, Chris Cheshire wrote:
>> I see in the changelog for 8.5.24
>> 
>> 60762: Add the ability to make changes to the TLS configuration
>> of a connector at runtime without having to restart the
>> Connector. (markt)
>> 
>> Does this mean we can now update SSL certificates without
>> bouncing the connector?
> 
> Yes, via one of the following methods on the endpoint:
> 
> reloadSslHostConfig(String hostName) reloadSslHostConfigs()
> 
> If accessing this via JMX, they appear as operations on the
> ThreadPool objects.

I'll be very happy to update my "Let's Encrypt" presentation to
reflect the new situation :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlohhFUdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgNERAAx6sc8sdD6YXKw6uO
KEkka/SHtPmPfxGUl55j/DhhIgColGMg4Vp03BA7OoGSZp2UMQwv/Nxw8y94J4wd
G/DTntqWFsR+fO1sc0t7EQq7is3VhMRMcGA7jE9PYyjuDT8ynnua7UcQxlhx0LCw
cZSM5RTPBjNgbazV/BJDJeNRX268fbflJvwUrDIS2p3ZF3gwgdxjVva3OEt67KBQ
3iRnYvtDPUbmfHFr7EyC7kQaM5N+VCNRT8iMmoIEvY892JwBfBP5fGaSSSFF8kLK
Hdu8R8Er+MuFiLA9QBRLcknpzAWiMMZMV27XdU/Pr3oH7G+zWlbVbDCCxSKVGOQE
+NQNYp2tAVM8KjX0x5w7uExD7uBzTGE1GMzjJYGOzw+se7XSXlTC9Go6d1y9mq4i
M2Td+A6rnRuFyg10VNuu3HZicA23c9Ry2VQu03K2JA9nNYoL6ssujy1J1S5OWHnh
I0qWwcD3qCcay6vVYzGhXYUAhTFAQ/OGLa+G3zpZHo+rMyY5JutPkGjRt1PabqPr
A3YJtO0i431SyWapnc/iCH9BG0+21kzckaSJS9ri5yvOjJk+okoP6PIa1NJNj8lf
IFVQ5oagfTqPuRzcc6U9DxbDd/qTAffn6Nw/9xPE5y9rA72mZDbTcYNjgeu34ft/
NVONR4PwFO4ScBGr1Bd90ov0ky8=
=4pKT
-END PGP SIGNATURE-

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

Re: SSL connectors

[Mark Thomas]

On 01/12/17 14:57, Chris Cheshire wrote:
> I see in the changelog for 8.5.24
> 
> 60762: Add the ability to make changes to the TLS configuration of a
> connector at runtime without having to restart the Connector. (markt)
> 
> Does this mean we can now update SSL certificates without bouncing the
> connector?

Yes, via one of the following methods on the endpoint:

reloadSslHostConfig(String hostName)
reloadSslHostConfigs()

If accessing this via JMX, they appear as operations on the ThreadPool
objects.

Mark

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

Re: SSL is not working

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

M.,

On 8/4/17 12:16 PM, M. Manna wrote:
> Have you imported the signed server certificate into the server
> keystore with all the root+intermediate certificates? in other
> words, does the "chain-of-trust" exist in server keystore?
> 
> You just need to add the root and intermediate CA certs to trust
> store - any server certs signed by them is by default, trusted.

No, you definitely don't want to mess around with any trust stores.

Here are the instructions I always follow when using Java keystores
(which are in fact so awful that even Java is giving up on them[1]),
copied directly from my corporate wiki page on the subject (which I
wrote because I can never remember all the steps):

== Create a New Server Key & Certificate with Java's Keytool

Make sure to use Java's keytool with a Java version 1.6 or better.

 $ keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 4096
- -alias ${HOSTNAME} -keystore ${HOSTNAME}.jks

== Generate a CSR to send to a CA using Java's Keytool

 $ keytool -certreq -sigalg SHA256withRSA -keystore ${HOSTNAME}.jks

If you have more than one certificate in there, you'll need to use the
"-alias" option.

== Import a Signed Certificate into your Keystore

You'll need to import the root and intermediate certificates from the
CA first:

 $ keytool -import -alias [Authority.CA] -trustcacerts -file
[authority's CA cert] -keystore ${HOSTNAME}.jks
 $ keytool -import -alias [Authority.intermediate] -trustcacerts -file
[authority's intermediate cert] -keystore ${HOSTNAME}.jks
 $ keytool -import -alias ${HOSTNAME} -file ${HOSTNAME}.crt -keystore
${HOSTNAME}.jks

Note that the order of import matters. If you do this in the opposite
order, I think your server catches fire instantly. Java keystores are
*just that bad*.

Hope that helps,
- -chris

[1] http://openjdk.java.net/jeps/229

> On 4 August 2017 at 17:09, Hameed, Amir 
> wrote:
> 
>> Hi, I am trying to configure Tomcat 8.0.36 with SSL and running
>> into some issues. The JDK version I am using is 1.8.0_64. I used
>> the following process to implement SSL:
>> 
>> 1.   Generated a java key store using the following command: 
>> ${JAVA_HOME}/bin/keytool -genkey -alias [alias-name] -keyalg RSA
>> -keysize 2048 \ -keystore [key-store-path]/keystore.jks -dname
>> "CN=[common-name],OU=[org-unit], O=[company-name], L=[city],
>> ST=[state], C=US"
>> 
>> 
>> 2.   Generated CSR using the following command: 
>> ${JAVA_HOME}/bin/keytool -certreq -alias [alias-name] -file 
>> [key-store-path]/[csr-file-name] \ -keystore
>> [key-store-path]/keystore.jks
>> 
>> 
>> 3.   Requested certificate from COMODO.
>> 
>> 4.   Imported all Trusted certificates from COMODO into the
>> key store using command. There were a total of three trusted
>> certificates that we received from COMODO: 
>> ${JAVA_HOME}/bin/keytool -import -trustcacerts -alias
>> [alias-name] -file [ssl-cert-file] -keystore
>> [key-store-path]/keystore.jks -v
>> 
>> 
>> 5.   Modified Tomcat's server.xml file as shown below:
>> 
>> > 
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>> 
>> clientAuth="false" sslProtocol="TLS"
>> 
>> keystoreFile="[key-store-path]/keystore.jks"
>> 
>> keystoreType="JKS" keystorePass="[key-store-password]" />
>> 
>> 
>> 
>> 6.   Restarted Tomcat.
>> 
>> 7.   Accessed the Tomcat homepage from the browser using
>> https and the browser complained about page being insecure. When
>> I looked at the certificate from the browser, I see that the
>> Certificate Path tab of the certificate shows that the trusted
>> chain is incomplete and does not show the trusted certificates
>> that I had imported into the key store.
>> 
>> What am I missing here? Any help will be appreciated.
>> 
>> 
>> Thank you, Amir
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZhO37AAoJEBzwKT+lPKRYXFMP/jfiWrKQR5dTzarkJdJa39oN
to4WNYH6wfdONcRhQUHggVAid4qPjs567XjGWfRfnZvaxNhQu52rQN7+tbsFwt7i
wTeURIYK0c/xiO6fvUSvc9A5QkXvMUu2vrPy4V6btMxZSmvktxpTMG0iALbUeobv
Jr42EzE6WZ1Lgj6NoGyJIBkCebfu6HRySOWHIi3rQKBSab3sVYf65mryn6zGw8pq
ZMR8daqsrUdrt9f3ZCqCZjWNHk96fTdh2OUvKIFm58ux0bhj+s5LDpBq4LYTDww1
OxFLOlmxqZ1iy0UmnvNCeEagrMveg1XVRYEbH4jBHsW3nCktzUPa62iLE9I25CnN
iBdoGbHD9gal0PdA6+tbw4aZFvEFzqnLp4LSSwQ2Jm+6vb8SpS0/g6a5T0jrR+0j
GQ9bvfZA4MtmrS4+MZOhEBiv0RGmeoaRv/UDIdsOZdzVGfQkqH5vDqoIEZhRH9Wb
7BC5Sw7TyDM5ylT1vjIxucoaPVFc+uWLFZbUMA57tqlfYlxX6oc3ZhnvEZhP49+0
ridFkN1BY7X42flXnoztbc8B0iRj/jFymnHXQcfpL5Vnc48OSdSPktDVnfm8Q9ZF
jZJVzLfn3Og5+FhmBZH+mwAz5nxFN8naEuaSmpUGx0MVcqHBXHHGFd7E7axtUA+e
twkhpNDyccC7mPAVv3ke
=F7Z0
-END PGP SIGNATURE-

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

Re: SSL is not working

[M. Manna]

My bad - you can ignore my previous email - i was thinking about some other
scenario.

If the message says "Trusted Chain is Incomplete" - that means that your
browser's certificate store doesn't have the updated information regarding
root+intermediate CA certs. If you have import all the certificates
correctly to your server keystore this shouldn't be happening.
Check this post to see if you find any missing steps -
https://www.digicert.com/util/repair-intermediate-ssl-certificate-errors-using-digicert-utility-for-microsoft-servers.htm
.

Regards,

On 4 August 2017 at 17:38, M. Manna <manme...@gmail.com> wrote:

> if you are testing locally (i.e. on localhost) you might want to check if
> the root and intermediate CA exists. Or just import it
> 1. Find out where your jdk is - say JDK_PATH
> 2. keep a backup copy somewhere for JDK_PATH\jre\lib\security\cacerts
> 2. run the following command for each root/intermediate CA cert
> keytool -import -trustcacerts -keystore JDK_PATH\jre\lib\security\cacerts
> -storepass changeit -noprompt -file CA_FILE_LOCATION
>
> Restart your tomcat. and check.
>
>
>
> On 4 August 2017 at 17:23, Hameed, Amir <amir.ham...@xerox.com> wrote:
>
>> Thank you for your reply. Please see my answers below:
>>
>> Have you imported the signed server certificate into the server keystore
>> with all the root+intermediate certificates? in other words, does the
>> "chain-of-trust" exist in server keystore?
>> >> Yes, I have imported all trusted certificates (COMODORSAAddTrustCA.crt
>> + AddTrustExternalCARoot.crt + 
>> COMODORSAOrganizationValidationSecureServerCA.crt)
>> into the server key store along with the signed server certificate.
>>
>> You just need to add the root and intermediate CA certs to trust store -
>> any server certs signed by them is by default, trusted.
>> >> I am new to Tomcat. Where can I find the trust store and is it
>> separate from the server key store?
>>
>> Thanks
>> -Original Message-
>> From: M. Manna [mailto:manme...@gmail.com]
>> Sent: Friday, August 4, 2017 12:16 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: SSL is not working
>>
>> Have you imported the signed server certificate into the server keystore
>> with all the root+intermediate certificates? in other words, does the
>> "chain-of-trust" exist in server keystore?
>>
>> You just need to add the root and intermediate CA certs to trust store -
>> any server certs signed by them is by default, trusted.
>>
>>
>> On 4 August 2017 at 17:09, Hameed, Amir <amir.ham...@xerox.com> wrote:
>>
>> > Hi,
>> > I am trying to configure Tomcat 8.0.36 with SSL and running into some
>> > issues. The JDK version I am using is 1.8.0_64. I used the following
>> > process to implement SSL:
>> >
>> > 1.   Generated a java key store using the following command:
>> > ${JAVA_HOME}/bin/keytool -genkey -alias [alias-name] -keyalg RSA
>> > -keysize
>> > 2048 \
>> > -keystore [key-store-path]/keystore.jks -dname
>> > "CN=[common-name],OU=[org-unit], O=[company-name], L=[city],
>> ST=[state], C=US"
>> >
>> >
>> > 2.   Generated CSR using the following command:
>> > ${JAVA_HOME}/bin/keytool -certreq -alias [alias-name] -file
>> > [key-store-path]/[csr-file-name] \ -keystore
>> > [key-store-path]/keystore.jks
>> >
>> >
>> > 3.   Requested certificate from COMODO.
>> >
>> > 4.   Imported all Trusted certificates from COMODO into the key
>> store
>> > using command. There were a total of three trusted certificates that
>> > we received from COMODO:
>> > ${JAVA_HOME}/bin/keytool -import -trustcacerts -alias [alias-name]
>> > -file [ssl-cert-file] -keystore [key-store-path]/keystore.jks -v
>> >
>> >
>> > 5.   Modified Tomcat's server.xml file as shown below:
>> >
>> > > >
>> >maxThreads="150" SSLEnabled="true" scheme="https"
>> > secure="true"
>> >
>> >clientAuth="false" sslProtocol="TLS"
>> >
>> >keystoreFile="[key-store-path]/keystore.jks"
>> >
>> >keystoreType="JKS" keystorePass="[key-store-password]"
>> > />
>> >
>> >
>> >
>> > 6.   Restarted Tomcat.
>> >
>> > 7.   Accessed the Tomcat homepage from the browser using https and
>> the
>> > browser complained about page being insecure. When I looked at the
>> > certificate from the browser, I see that the Certificate Path tab of
>> > the certificate shows that the trusted chain is incomplete and does
>> > not show the trusted certificates that I had imported into the key
>> store.
>> >
>> > What am I missing here? Any help will be appreciated.
>> >
>> >
>> > Thank you,
>> > Amir
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: SSL is not working

[Chaitanya Sabbineni]

Hi,

please try to import the certificate into the browser.

Truststore and keystore or not different it depends on the name you give.
example: tomcat_keystore.keystore or tomcat_trust.keystore and need to
provide the respective path and the password in the keystore.

please make sure that same alias name has to used through out the process.

please make sure if your keystore contains any private key entries using
keytool -list - v command. If you had imported proper ssl cert with proper
alias name then ideally you should have private key entry over here.

Thanks


On Fri, 4 Aug 2017 9:53 pm Hameed, Amir, <amir.ham...@xerox.com> wrote:

> Thank you for your reply. Please see my answers below:
>
> Have you imported the signed server certificate into the server keystore
> with all the root+intermediate certificates? in other words, does the
> "chain-of-trust" exist in server keystore?
> >> Yes, I have imported all trusted certificates (COMODORSAAddTrustCA.crt
> + AddTrustExternalCARoot.crt +
> COMODORSAOrganizationValidationSecureServerCA.crt) into the server key
> store along with the signed server certificate.
>
> You just need to add the root and intermediate CA certs to trust store -
> any server certs signed by them is by default, trusted.
> >> I am new to Tomcat. Where can I find the trust store and is it separate
> from the server key store?
>
> Thanks
> -Original Message-
> From: M. Manna [mailto:manme...@gmail.com]
> Sent: Friday, August 4, 2017 12:16 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: SSL is not working
>
> Have you imported the signed server certificate into the server keystore
> with all the root+intermediate certificates? in other words, does the
> "chain-of-trust" exist in server keystore?
>
> You just need to add the root and intermediate CA certs to trust store -
> any server certs signed by them is by default, trusted.
>
>
> On 4 August 2017 at 17:09, Hameed, Amir <amir.ham...@xerox.com> wrote:
>
> > Hi,
> > I am trying to configure Tomcat 8.0.36 with SSL and running into some
> > issues. The JDK version I am using is 1.8.0_64. I used the following
> > process to implement SSL:
> >
> > 1.   Generated a java key store using the following command:
> > ${JAVA_HOME}/bin/keytool -genkey -alias [alias-name] -keyalg RSA
> > -keysize
> > 2048 \
> > -keystore [key-store-path]/keystore.jks -dname
> > "CN=[common-name],OU=[org-unit], O=[company-name], L=[city], ST=[state],
> C=US"
> >
> >
> > 2.   Generated CSR using the following command:
> > ${JAVA_HOME}/bin/keytool -certreq -alias [alias-name] -file
> > [key-store-path]/[csr-file-name] \ -keystore
> > [key-store-path]/keystore.jks
> >
> >
> > 3.   Requested certificate from COMODO.
> >
> > 4.   Imported all Trusted certificates from COMODO into the key store
> > using command. There were a total of three trusted certificates that
> > we received from COMODO:
> > ${JAVA_HOME}/bin/keytool -import -trustcacerts -alias [alias-name]
> > -file [ssl-cert-file] -keystore [key-store-path]/keystore.jks -v
> >
> >
> > 5.   Modified Tomcat's server.xml file as shown below:
> >
> >  >
> >maxThreads="150" SSLEnabled="true" scheme="https"
> > secure="true"
> >
> >clientAuth="false" sslProtocol="TLS"
> >
> >keystoreFile="[key-store-path]/keystore.jks"
> >
> >keystoreType="JKS" keystorePass="[key-store-password]"
> > />
> >
> >
> >
> > 6.   Restarted Tomcat.
> >
> > 7.   Accessed the Tomcat homepage from the browser using https and
> the
> > browser complained about page being insecure. When I looked at the
> > certificate from the browser, I see that the Certificate Path tab of
> > the certificate shows that the trusted chain is incomplete and does
> > not show the trusted certificates that I had imported into the key store.
> >
> > What am I missing here? Any help will be appreciated.
> >
> >
> > Thank you,
> > Amir
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: SSL is not working

[M. Manna]

if you are testing locally (i.e. on localhost) you might want to check if
the root and intermediate CA exists. Or just import it
1. Find out where your jdk is - say JDK_PATH
2. keep a backup copy somewhere for JDK_PATH\jre\lib\security\cacerts
2. run the following command for each root/intermediate CA cert
keytool -import -trustcacerts -keystore JDK_PATH\jre\lib\security\cacerts
-storepass changeit -noprompt -file CA_FILE_LOCATION

Restart your tomcat. and check.



On 4 August 2017 at 17:23, Hameed, Amir <amir.ham...@xerox.com> wrote:

> Thank you for your reply. Please see my answers below:
>
> Have you imported the signed server certificate into the server keystore
> with all the root+intermediate certificates? in other words, does the
> "chain-of-trust" exist in server keystore?
> >> Yes, I have imported all trusted certificates (COMODORSAAddTrustCA.crt
> + AddTrustExternalCARoot.crt + 
> COMODORSAOrganizationValidationSecureServerCA.crt)
> into the server key store along with the signed server certificate.
>
> You just need to add the root and intermediate CA certs to trust store -
> any server certs signed by them is by default, trusted.
> >> I am new to Tomcat. Where can I find the trust store and is it separate
> from the server key store?
>
> Thanks
> -Original Message-
> From: M. Manna [mailto:manme...@gmail.com]
> Sent: Friday, August 4, 2017 12:16 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: SSL is not working
>
> Have you imported the signed server certificate into the server keystore
> with all the root+intermediate certificates? in other words, does the
> "chain-of-trust" exist in server keystore?
>
> You just need to add the root and intermediate CA certs to trust store -
> any server certs signed by them is by default, trusted.
>
>
> On 4 August 2017 at 17:09, Hameed, Amir <amir.ham...@xerox.com> wrote:
>
> > Hi,
> > I am trying to configure Tomcat 8.0.36 with SSL and running into some
> > issues. The JDK version I am using is 1.8.0_64. I used the following
> > process to implement SSL:
> >
> > 1.   Generated a java key store using the following command:
> > ${JAVA_HOME}/bin/keytool -genkey -alias [alias-name] -keyalg RSA
> > -keysize
> > 2048 \
> > -keystore [key-store-path]/keystore.jks -dname
> > "CN=[common-name],OU=[org-unit], O=[company-name], L=[city],
> ST=[state], C=US"
> >
> >
> > 2.   Generated CSR using the following command:
> > ${JAVA_HOME}/bin/keytool -certreq -alias [alias-name] -file
> > [key-store-path]/[csr-file-name] \ -keystore
> > [key-store-path]/keystore.jks
> >
> >
> > 3.   Requested certificate from COMODO.
> >
> > 4.   Imported all Trusted certificates from COMODO into the key store
> > using command. There were a total of three trusted certificates that
> > we received from COMODO:
> > ${JAVA_HOME}/bin/keytool -import -trustcacerts -alias [alias-name]
> > -file [ssl-cert-file] -keystore [key-store-path]/keystore.jks -v
> >
> >
> > 5.   Modified Tomcat's server.xml file as shown below:
> >
> >  >
> >maxThreads="150" SSLEnabled="true" scheme="https"
> > secure="true"
> >
> >clientAuth="false" sslProtocol="TLS"
> >
> >keystoreFile="[key-store-path]/keystore.jks"
> >
> >keystoreType="JKS" keystorePass="[key-store-password]"
> > />
> >
> >
> >
> > 6.   Restarted Tomcat.
> >
> > 7.   Accessed the Tomcat homepage from the browser using https and
> the
> > browser complained about page being insecure. When I looked at the
> > certificate from the browser, I see that the Certificate Path tab of
> > the certificate shows that the trusted chain is incomplete and does
> > not show the trusted certificates that I had imported into the key store.
> >
> > What am I missing here? Any help will be appreciated.
> >
> >
> > Thank you,
> > Amir
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: SSL is not working

[Hameed, Amir]

Thank you for your reply. Please see my answers below:

Have you imported the signed server certificate into the server keystore with 
all the root+intermediate certificates? in other words, does the 
"chain-of-trust" exist in server keystore?
>> Yes, I have imported all trusted certificates (COMODORSAAddTrustCA.crt + 
>> AddTrustExternalCARoot.crt + 
>> COMODORSAOrganizationValidationSecureServerCA.crt) into the server key store 
>> along with the signed server certificate.

You just need to add the root and intermediate CA certs to trust store - any 
server certs signed by them is by default, trusted.
>> I am new to Tomcat. Where can I find the trust store and is it separate from 
>> the server key store?

Thanks
-Original Message-
From: M. Manna [mailto:manme...@gmail.com] 
Sent: Friday, August 4, 2017 12:16 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL is not working

Have you imported the signed server certificate into the server keystore with 
all the root+intermediate certificates? in other words, does the 
"chain-of-trust" exist in server keystore?

You just need to add the root and intermediate CA certs to trust store - any 
server certs signed by them is by default, trusted.


On 4 August 2017 at 17:09, Hameed, Amir <amir.ham...@xerox.com> wrote:

> Hi,
> I am trying to configure Tomcat 8.0.36 with SSL and running into some 
> issues. The JDK version I am using is 1.8.0_64. I used the following 
> process to implement SSL:
>
> 1.   Generated a java key store using the following command:
> ${JAVA_HOME}/bin/keytool -genkey -alias [alias-name] -keyalg RSA 
> -keysize
> 2048 \
> -keystore [key-store-path]/keystore.jks -dname 
> "CN=[common-name],OU=[org-unit], O=[company-name], L=[city], ST=[state], C=US"
>
>
> 2.   Generated CSR using the following command:
> ${JAVA_HOME}/bin/keytool -certreq -alias [alias-name] -file 
> [key-store-path]/[csr-file-name] \ -keystore 
> [key-store-path]/keystore.jks
>
>
> 3.   Requested certificate from COMODO.
>
> 4.   Imported all Trusted certificates from COMODO into the key store
> using command. There were a total of three trusted certificates that 
> we received from COMODO:
> ${JAVA_HOME}/bin/keytool -import -trustcacerts -alias [alias-name] 
> -file [ssl-cert-file] -keystore [key-store-path]/keystore.jks -v
>
>
> 5.   Modified Tomcat's server.xml file as shown below:
>
> 
>maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true"
>
>clientAuth="false" sslProtocol="TLS"
>
>keystoreFile="[key-store-path]/keystore.jks"
>
>keystoreType="JKS" keystorePass="[key-store-password]" 
> />
>
>
>
> 6.   Restarted Tomcat.
>
> 7.   Accessed the Tomcat homepage from the browser using https and the
> browser complained about page being insecure. When I looked at the 
> certificate from the browser, I see that the Certificate Path tab of 
> the certificate shows that the trusted chain is incomplete and does 
> not show the trusted certificates that I had imported into the key store.
>
> What am I missing here? Any help will be appreciated.
>
>
> Thank you,
> Amir
>
>

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

Re: SSL is not working

[M. Manna]

Have you imported the signed server certificate into the server keystore
with all the root+intermediate certificates? in other words, does the
"chain-of-trust" exist in server keystore?

You just need to add the root and intermediate CA certs to trust store -
any server certs signed by them is by default, trusted.


On 4 August 2017 at 17:09, Hameed, Amir  wrote:

> Hi,
> I am trying to configure Tomcat 8.0.36 with SSL and running into some
> issues. The JDK version I am using is 1.8.0_64. I used the following
> process to implement SSL:
>
> 1.   Generated a java key store using the following command:
> ${JAVA_HOME}/bin/keytool -genkey -alias [alias-name] -keyalg RSA -keysize
> 2048 \
> -keystore [key-store-path]/keystore.jks -dname 
> "CN=[common-name],OU=[org-unit],
> O=[company-name], L=[city], ST=[state], C=US"
>
>
> 2.   Generated CSR using the following command:
> ${JAVA_HOME}/bin/keytool -certreq -alias [alias-name] -file
> [key-store-path]/[csr-file-name] \
> -keystore [key-store-path]/keystore.jks
>
>
> 3.   Requested certificate from COMODO.
>
> 4.   Imported all Trusted certificates from COMODO into the key store
> using command. There were a total of three trusted certificates that we
> received from COMODO:
> ${JAVA_HOME}/bin/keytool -import -trustcacerts -alias [alias-name] -file
> [ssl-cert-file] -keystore [key-store-path]/keystore.jks -v
>
>
> 5.   Modified Tomcat's server.xml file as shown below:
>
> 
>maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true"
>
>clientAuth="false" sslProtocol="TLS"
>
>keystoreFile="[key-store-path]/keystore.jks"
>
>keystoreType="JKS" keystorePass="[key-store-password]" />
>
>
>
> 6.   Restarted Tomcat.
>
> 7.   Accessed the Tomcat homepage from the browser using https and the
> browser complained about page being insecure. When I looked at the
> certificate from the browser, I see that the Certificate Path tab of the
> certificate shows that the trusted chain is incomplete and does not show
> the trusted certificates that I had imported into the key store.
>
> What am I missing here? Any help will be appreciated.
>
>
> Thank you,
> Amir
>
>

Re: SSL on Tomcat7 on AWS not connecting

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 11/17/16 4:48 PM, George Chanady wrote:
> Chris,
> 
> I tried curl with the -tls1 switch and received the same error.
> 
> [ec2-user@ip-172-31-52-159 bin]$ curl -vk
> https://bageoconsultants.com:8443 -tls1 * Rebuilt URL to:
> https://bageoconsultants.com:8443/ *   Trying 52.54.85.95... *
> Connected to bageoconsultants.com (52.54.85.95) port 8443 (#0) *
> Initializing NSS with certpath: sql:/etc/pki/nssdb * NSS error
> -12286 (SSL_ERROR_NO_CYPHER_OVERLAP) * Cannot communicate securely
> with peer: no common encryption algorithm(s). * Closing connection
> 0 curl: (35) Cannot communicate securely with peer: no common
> encryption algorithm(s).
> 
> I also tried with openssl s_client which was the last few lines of
> my of the original attachment. Also a no go,
> 
> [ec2-user@ip-172-31-34-217 conf]$ openssl s_client -connect
> bageoconsultants.com:8443 CONNECTED(0003) 
> 140427891013472:error:14077410:SSL
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
> failure:s23_clnt.c:770: --- no peer certificate available --- No
> client certificate CA names sent --- SSL handshake has read 7 bytes
> and written 249 bytes --- New, (NONE), Cipher is (NONE) Secure
> Renegotiation IS NOT supported Compression: NONE Expansion: NONE 
> ---

s_client will also need the same switch, except it's like this for
s_client:

$ openssl s_client -tls1 -connect bageoconsultants.com:8443

That's not a publicly-accessible port or I would be able to check it
myself.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYL10YAAoJEBzwKT+lPKRYwwsQAKmZbWizrj4nkcF9pBCtDcV/
SngmsgtyTKgljJFGBr2ii3StHux06pCrWwsVN+/nIS9KFtZ4bgRWJ00RssqFbJgP
gaEdQf0av6wr04S7J0t6ub5ZsOpsR07YczCLCO1oe7ri6aOGrilulYTGx/e1K4H/
ry3r8QmyXaqoA6Y8NTA7mnibGUDH+AfB10acGf65lKaXzWsKm2PFdZD4ICwfsUQt
G5H4ydtIdOg9t4+FQpwWrOAjopnAysvtMJ6GmUKSXuoWTGjucUktIDfVB0KknczL
0JNn7O3HZ8H+mPEJwuckMjcLfRHVUE7GsZoHsyR1XJve6kPj2dJGmgAb26ygFb9X
ZCY8/jO99Zo64NSkoEWyHOgn1WFBshvrgHiW2J+O8FU72JCK8AQU62J4KlGWA8+/
JgULR8VlaNDPYA0u/XKiYTwAF1Jev/WXySrvlNtLysa8lPb0CWG3XA5CqATViUYT
V9MCJ5CvMfiQ1k1Q4T4Om1sRWE6GgN6/IxcUtkJ2ZN2d/tt1tUV0CIusdXwEVjXR
7kX0pha/876/C/K65odT0El3V6LClod46sfBbOX1wjr0sBClJ8PnfPlQtBlIhn8n
3ex6IhsNGo7Ip3Mrx4zN5q9wETiLVc1Drag8DkTnkCrLPdXJWVatts5X54BV8aPE
63ZuEKzFb3prNziOgN0F
=JzKd
-END PGP SIGNATURE-

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

RE: SSL on Tomcat7 on AWS not connecting

[George Chanady]

Hi Igor,






I am too new at Linux to know if the output from this is bad, other than the 
first line. Not really sure what the rest is telling me. 

[ec2-user@ip-172-31-52-159 logs]$ tail -f catalina.out
java.lang.IllegalArgumentException: Invalid character found in method name. 
HTTP method names must be tokens
at 
org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:136)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1000)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

Thanks,

--George


-Original Message-
From: Igor Cicimov [mailto:icici...@gmail.com] 
Sent: Wednesday, November 16, 2016 8:48 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL on Tomcat7 on AWS not connecting

On 17 Nov 2016 4:38 am, "George Chanady" <gchan...@webhse.com> wrote:
>
> I hope someone can help.I have exhausted all my troubleshooting skills
and all of my newbie Linux knowledge and I am at the end of my rope.
>
> All documentation from around the web always seem to tell me to try
everything I have already tried. I am sure that there must be a caveat that I 
am missing.
>
> I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the 
> life
of me get the SSL working.
>
> I set up the AWS instance with nothing else on the server and using a
fresh installation of Tomcat  with basic config settings. I am able to connect 
http://mysite.com:8080 but cannot connect with https://mysite.com:8443.
> I am able to SSH as that is the only way I communicate with the server.
>
> I only have forwarders for port 80 and 443 in the iptables and nothing
else and have security groups in AWS setup to allow all traffic from everywhere 
for ports 80, 8080, 443, and 8443.
>
> I have ensured the ports needed are open and listening using netstat I 
> have checked to ensure connectivity to the ports from other machines
using netcat
> I checked that the certs were installed properly and that the tomcat
connectors were pointed the proper location
>
> I am attaching my configuration from start to where I hit the wall.
>
> Thanks in advance for any assistance.
>
And you are sure the keystore loads properly?



Are those values for keystoreFile and keystorePass correct? Do you see any 
errors in catalina.out log?


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

RE: SSL on Tomcat7 on AWS not connecting

[George Chanady]

Chris,

I tried curl with the -tls1 switch and received the same error.

[ec2-user@ip-172-31-52-159 bin]$ curl -vk https://bageoconsultants.com:8443 
-tls1
* Rebuilt URL to: https://bageoconsultants.com:8443/
*   Trying 52.54.85.95...
* Connected to bageoconsultants.com (52.54.85.95) port 8443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption 
algorithm(s).
* Closing connection 0
curl: (35) Cannot communicate securely with peer: no common encryption 
algorithm(s).

I also tried with openssl s_client which was the last few lines of my of the 
original attachment.
Also a no go,

[ec2-user@ip-172-31-34-217 conf]$ openssl s_client -connect 
bageoconsultants.com:8443
CONNECTED(0003)
140427891013472:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Thanks
--George



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, November 17, 2016 9:58 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL on Tomcat7 on AWS not connecting

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 11/16/16 12:38 PM, George Chanady wrote:
> I hope someone can help.I have exhausted all my troubleshooting skills 
> and all of my newbie Linux knowledge and I am at the end of my rope.
> 
> All documentation from around the web always seem to tell me to try 
> everything I have already tried. I am sure that there must be a caveat 
> that I am missing.
> 
> I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the 
> life of me get the SSL working.
> 
> I set up the AWS instance with nothing else on the server and using a 
> fresh installation of Tomcat  with basic config settings. I am able to 
> connect http://mysite.com:8080 but cannot connect with 
> https://mysite.com:8443. I am able to SSH as that is the only way I 
> communicate with the server.
> 
> I only have forwarders for port 80 and 443 in the iptables and nothing 
> else and have security groups in AWS setup to allow all traffic from 
> everywhere for ports 80, 8080, 443, and 8443.
> 
> I have ensured the ports needed are open and listening using netstat I 
> have checked to ensure connectivity to the ports from other machines 
> using netcat I checked that the certs were installed properly and that 
> the tomcat connectors were pointed the proper location
> 
> I am attaching my configuration from start to where I hit the wall.

What if you give curl the --tls1 switch?

Can you try with openssl s_client? I find that tends to give more information 
about the conversation.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYLcVwAAoJEBzwKT+lPKRY+7UQAIURP7wWTMinfL8E28SERuwK
NsyvBQOEsWXSHweN5tkmgqiUF7zWcYFf0j+reDpaEvR9KIV+Wd1vI/LvCqQO7wEA
p8Nv+jvet3ObWOInN9A0HcZsf8H5bpuIrE0a2d/B5P2EIFEOlESgjhgyEjcNEVL/
LFwSZX+rCbtzt/vSSk8fQpout7+5jaYIOLOhxmB4qAvBJI3dLXOV4d3Kfty+FxrK
JfUwBDsS4RdZoH+i52XXemERR+Y5cIcpNul2BFQ0xo2knRfVPl1b1mzWxJGuAFbI
lHZr9QuyaOymgYJ6PTGRQZXx2jXCdYM7U8ryTShTeiGC8b5IMfMF9z2E3qRfdcAw
RZXaDJ3GKVPcZcGBvFCtP6G5I1UiOi6PrXu/TkjmfG8tlyqA3dkXyH/dIYUYuO0Y
h65brIcLNZZbiOECX0v/jupMlnHa584cZcYOnvXF9wrfBQb3d62PFf4DRO+a0ozk
AKEGxBdGt75KzMpb5PS6pH+T74P6LHqrCTEzZ63G9O0No0CSKFwRizb+4DGeOTDN
dYk7Bx7+HolYe1u02mBgEfgfwItrj8131ddHoHSp8btYVyJ+2HfmI9DOJV9Cxo+r
1aa0DeIsu6G24TkFrpNzn+SgBYyZdp/+lNeWnxbz4fu4wMLcetVbpSdSjQ8xeKna
uIACDouiyhLDNYXgVhmz
=/Z5J
-END PGP SIGNATURE-

-
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

Re: SSL on Tomcat7 on AWS not connecting

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 11/16/16 12:38 PM, George Chanady wrote:
> I hope someone can help.I have exhausted all my troubleshooting
> skills and all of my newbie Linux knowledge and I am at the end of
> my rope.
> 
> All documentation from around the web always seem to tell me to
> try everything I have already tried. I am sure that there must be a
> caveat that I am missing.
> 
> I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the
> life of me get the SSL working.
> 
> I set up the AWS instance with nothing else on the server and using
> a fresh installation of Tomcat  with basic config settings. I am
> able to connect http://mysite.com:8080 but cannot connect with 
> https://mysite.com:8443. I am able to SSH as that is the only way I
> communicate with the server.
> 
> I only have forwarders for port 80 and 443 in the iptables and
> nothing else and have security groups in AWS setup to allow all
> traffic from everywhere for ports 80, 8080, 443, and 8443.
> 
> I have ensured the ports needed are open and listening using
> netstat I have checked to ensure connectivity to the ports from
> other machines using netcat I checked that the certs were installed
> properly and that the tomcat connectors were pointed the proper
> location
> 
> I am attaching my configuration from start to where I hit the
> wall.

What if you give curl the --tls1 switch?

Can you try with openssl s_client? I find that tends to give more
information about the conversation.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYLcVwAAoJEBzwKT+lPKRY+7UQAIURP7wWTMinfL8E28SERuwK
NsyvBQOEsWXSHweN5tkmgqiUF7zWcYFf0j+reDpaEvR9KIV+Wd1vI/LvCqQO7wEA
p8Nv+jvet3ObWOInN9A0HcZsf8H5bpuIrE0a2d/B5P2EIFEOlESgjhgyEjcNEVL/
LFwSZX+rCbtzt/vSSk8fQpout7+5jaYIOLOhxmB4qAvBJI3dLXOV4d3Kfty+FxrK
JfUwBDsS4RdZoH+i52XXemERR+Y5cIcpNul2BFQ0xo2knRfVPl1b1mzWxJGuAFbI
lHZr9QuyaOymgYJ6PTGRQZXx2jXCdYM7U8ryTShTeiGC8b5IMfMF9z2E3qRfdcAw
RZXaDJ3GKVPcZcGBvFCtP6G5I1UiOi6PrXu/TkjmfG8tlyqA3dkXyH/dIYUYuO0Y
h65brIcLNZZbiOECX0v/jupMlnHa584cZcYOnvXF9wrfBQb3d62PFf4DRO+a0ozk
AKEGxBdGt75KzMpb5PS6pH+T74P6LHqrCTEzZ63G9O0No0CSKFwRizb+4DGeOTDN
dYk7Bx7+HolYe1u02mBgEfgfwItrj8131ddHoHSp8btYVyJ+2HfmI9DOJV9Cxo+r
1aa0DeIsu6G24TkFrpNzn+SgBYyZdp/+lNeWnxbz4fu4wMLcetVbpSdSjQ8xeKna
uIACDouiyhLDNYXgVhmz
=/Z5J
-END PGP SIGNATURE-

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

Re: SSL on Tomcat7 on AWS not connecting

[Igor Cicimov]

On 17 Nov 2016 4:38 am, "George Chanady"  wrote:
>
> I hope someone can help.I have exhausted all my troubleshooting skills
and all of my newbie Linux knowledge and I am at the end of my rope.
>
> All documentation from around the web always seem to tell me to try
everything I have already tried. I am sure that there must be a caveat that
I am missing.
>
> I have an AWS Linux instance with Tomcat 7.0.73 and cannot for the life
of me get the SSL working.
>
> I set up the AWS instance with nothing else on the server and using a
fresh installation of Tomcat  with basic config settings. I am able to
connect http://mysite.com:8080 but cannot connect with
https://mysite.com:8443.
> I am able to SSH as that is the only way I communicate with the server.
>
> I only have forwarders for port 80 and 443 in the iptables and nothing
else and have security groups in AWS setup to allow all traffic from
everywhere for ports 80, 8080, 443, and 8443.
>
> I have ensured the ports needed are open and listening using netstat
> I have checked to ensure connectivity to the ports from other machines
using netcat
> I checked that the certs were installed properly and that the tomcat
connectors were pointed the proper location
>
> I am attaching my configuration from start to where I hit the wall.
>
> Thanks in advance for any assistance.
>
And you are sure the keystore loads properly?



Are those values for keystoreFile and keystorePass correct? Do you see any
errors in catalina.out log?

Re: SSL digital cert for each context?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/2/16 11:59 AM, Mark Thomas wrote:
> On 02/11/2016 15:56, Andrea Galli wrote:
>> Hello guys,
>> 
>> I have configured SSL on Tomcat following this How-To: 
>> https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Introduction_
to_SSL
>>
>>
>>
>>
>> 
Everything works fine but this certificate is applied on all Tomcat cont
ext
>> that reside on webapps folder, my aim is implement different
>> digital cert for each context:
>> 
>> 
>> 
>> https://test.myfirstdomain.com:8080   have digital certificate
>> 
>> https://test.myseconddomain.com:8081   must have different
>> digital certificate
> 
> Those are different hosts, not different contexts. Big difference.
> 
>> It is possible without install Apache?
> 
> Yes. You need at least 8.5.x for TLS virtual hosting support.

This also requires Java 8 IIRC which is the first to support SNI
(which is what is really being requested, not just "TLS virtual
hosting" which of course already works, for some definition of "works".

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYGhlbAAoJEBzwKT+lPKRYe8QP/jNe5nXFHvFzyKhTSscB0p0C
o6eTXiRE8HFSZz82g4jYO2hD832yyn7DLKAtNJzZN0AoZBX7wO+KqqqYJX/BPJ9o
cySLVIqhRXF7Faa+fvvM96r0VuXLFNwXTDDn3M+fG07k00q//qTe2dypUZ6sA0OK
wbjejz4uKARPyNXZX7k0qDrRwrdZGF3Ake7JOQGmiLGApIrXgZ8Toh2zCKKsJ3O4
bfWnuZC/IWQgPZMImmsvO1AB/6F3j8o5mj4rcg3m7X43/IkfTyWISSiIufuoJzAH
DyGnQO/Sc3p84GQkC7VymdaF+Qey0l7QVgRBURZNJA3zdXBteryBBteHxxDBsvj9
qC/b5Z0OSFN0R+XRg0c0A+GsHR11oxVu+oEQA0wN+pdRt4IG6QOYspHvXdrmURfr
kbl7rN6YFLud3M1NsuyQgGpiQ1Wz5h96sXh8jQQrAjsrSyW1dZo3/vJiF1sPliSZ
Mo8ibUhymDSjqyHPMhmAPr/jYvc8Cbz02PogFYMqgAhKt90QC1KdWEPpyQjwdbCr
fv56xf+IEDUy2cO0E5QYiT3sQ3B6IhYBgJJipRqEcnsPiNo6c54Qpn5R++3BDdZr
vEmmqyLIwfHFtoR5U/WNJzLY28lUf3TAdmxFNf6JwVu78kJnIjl2acldecMP8HM3
47sqTBNxxSbnWSTUwxNr
=SaTc
-END PGP SIGNATURE-

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

Re: SSL digital cert for each context?

[Mark Thomas]

On 02/11/2016 15:56, Andrea Galli wrote:
> Hello guys,
> 
> I have configured SSL on Tomcat following this How-To:
> https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Introduction_to_SSL
> 
> 
> 
> Everything works fine but this certificate is applied on all Tomcat context
> that reside on webapps folder, my aim is implement different digital cert
> for each context:
> 
> 
> 
> https://test.myfirstdomain.com:8080   have digital certificate
> 
> https://test.myseconddomain.com:8081   must have different digital
> certificate

Those are different hosts, not different contexts. Big difference.

> It is possible without install Apache?

Yes. You need at least 8.5.x for TLS virtual hosting support.

Mark


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

Re: SSL setup - Apache Tomcat service won't start

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Khisanth,

On 9/26/16 7:45 AM, TJ wrote:
> I have Apache Tomcat/9.0.0.M10 on Windows 10 64bit and want to
> setup SSL.  Am following 
> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html  and gone 
> through the steps of creating the keystore with a single self
> signed cert using:
> 
> "%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA
> 
> Thats fine and confirmed the certificate is in there.
> 
> Next I alter the server.xml file as follows and go to restart the
> Tomcat service:
> 
> 
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol" 
> maxThreads="150" SSLEnabled="true" 
> keystoreFile="c:\users\khisanth\.keystore" keystorePass="changeit"
> />   certificateKeystoreFile="conf/localhost-rsa.jks" type="RSA" /> 
>  
> 
> Problem is the service will not restart. If I remove the added
> comments it will restart fine. I am logged in as administrator.

What do the logs say?

%CATALINA_BASE%\logs\catalina.log

or, if running as a Windows Service:

%CATALINA_BASE%\logs\stdout-*.log

While debugging startup errors, it's usually helpful to run Tomcat
interactively from the command prompt, like this:

C:\> %CATALINA_HOME%\bin\startup.bat

Then you get the stdout log right there in the terminal, including any
errors with the connector configurations.

> The apache server status page does mention HTTPS.

Apache httpd or Apache Tomcat?

- -chris

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX6tvtAAoJEBzwKT+lPKRYDHsQAIrw4rcFPwyG7AFEC9gK7z2D
uO+l8OmAnj3Kk8Sl+l3JVa4tkMFM9yXRgxCGd4dJEgQUypVP7K31/wg6OjzPpp/r
7iHseL2oJ5rLTfJXbB1y2BQQl/K55Y1M5dANSM3nmmy4+Mz8x8gNbFi+0FiUvgRv
JaIRUiEjn2tnUudDLQS0+E0p+IHhYgAuETr4X7p0CKkldMgb/f9w7avGSwDZBw9+
4a2pkLwXO9alvKT8X/LX92beVCG/OYXwCOVvInOJi6HUvkMLFN9k0RIji+V2rzYS
fUJ3AORZ9ODrtrQG/0dZJ/liZgX4uCbKSZBfi5cXbQP78nf8d8B9agjqDeVCFaJi
+vN7NEmooWg+AEAtboQwDj58MsoXfaN81Lb95ennBWPv/uqAYJwXlKHTBXadhG1W
f9j/dv+GIvBOa6YMh0z2OWzDS9gLD/R4d6ReIxsNnHdC9Iwsj/E1+dwpGSgDOVY/
O54IXRa2AD2hH8iuHRMGJQ5plWSeEBKZLQHLseXW0TdOZnpOiVNwAYB5vkp1QZ9V
zheM3Tb8Xqnt58dTx60NB2riMWblTagtwLOITwnoujcbtRXBCl3ARDu2gzUg52uH
aElGTDcHoGQAIGVTYeAhVHQm/lshb5WIE594ZHlC1ApQ+a6QWhXEuxM41GXzmQfH
5ZrxwnYwz/eCjLiq+VLX
=ZYYx
-END PGP SIGNATURE-

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

RE: SSL/TLS and ciphers vulnerability

[Robert Sulliman]

Hi All,

Just to add to this, I also have had issues with testing SSL setups in non 
prod environments that are not exposed to the internet.

I've been using testssl.sh for some time now and it has met my needs.

https://github.com/drwetter/testssl.sh

There are other open source solutions for internal scanning with a web front 
end like SSL Decoder, but this script works well if you are comfortable in 
Linux.

Cheers,

Robert Sulliman
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: July 15, 2016 7:49 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL/TLS and ciphers vulnerability

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

On 7/14/16 9:22 PM, Christopher Schultz wrote:
> Mark,
>
> On 7/14/16 4:14 PM, Mark Thomas wrote:
>> On 14/07/2016 19:36, uzair rashid wrote:
>>> Jeffrey,
>>>
>>> Working for a corporation that has strict ssl and security
>>> requirements.. There is no way to use the tools you suggested, since
>>> the tomcat URLs are not exposed.
>
>> That doesn't stop you setting up a stand-alone test instance using
>> the same settings (with a different cert if you are especially
>> paranoid) and checking those settings using the excellent ssllabs.
>
>> Keeping your Tomcat and JVM versions up to date will also help.
>> The Tomcat team periodically reviews Tomcat's default TLS
>> configuration and adjusts it accordingly. For details of the most
>> recent review see:
>> https://wiki.apache.org/tomcat/Security/Ciphers
>
> A few thoughts:
>
> [snip]
>
> 6. Qualys has a tool called ssllabs-scan available on GitHub:
> https://github.com/ssllabs/ssllabs-scan/
>
> [snip]
>
> The existence of the ssllabs-scan tool means it's also possible to
> set-up automated periodic scanning of your own site(s). If you expect
> to get an "A" rating and one day you aren't "A" quality any more, you
> should get an alarm without having to remember to manually-run the
> web-based tool when you get around to doing it.

And of course, such a thing already exists:
https://www.unixadm.org/nagios/check_sslscan

This tool uses SSLLabs's online tool so it would be subject to the same 
restrictions as the web-based version (e.g. no internal hosts).

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAleI6bYACgkQ9CaO5/Lv0PDDlgCgprkU2h++wmgOafv+mYsTwZOr
iikAnRyy1gBncREDypbnvb7sk27fypid
=Q6bW
-END PGP SIGNATURE-

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



smime.p7s
Description: S/MIME cryptographic signature

Re: SSL/TLS and ciphers vulnerability

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

On 7/14/16 9:22 PM, Christopher Schultz wrote:
> Mark,
> 
> On 7/14/16 4:14 PM, Mark Thomas wrote:
>> On 14/07/2016 19:36, uzair rashid wrote:
>>> Jeffrey,
>>> 
>>> Working for a corporation that has strict ssl and security 
>>> requirements.. There is no way to use the tools you suggested, 
>>> since the tomcat URLs are not exposed.
> 
>> That doesn't stop you setting up a stand-alone test instance
>> using the same settings (with a different cert if you are
>> especially paranoid) and checking those settings using the
>> excellent ssllabs.
> 
>> Keeping your Tomcat and JVM versions up to date will also help. 
>> The Tomcat team periodically reviews Tomcat's default TLS 
>> configuration and adjusts it accordingly. For details of the
>> most recent review see:
>> https://wiki.apache.org/tomcat/Security/Ciphers
> 
> A few thoughts:
> 
> [snip]
> 
> 6. Qualys has a tool called ssllabs-scan available on GitHub: 
> https://github.com/ssllabs/ssllabs-scan/
> 
> [snip]
> 
> The existence of the ssllabs-scan tool means it's also possible to 
> set-up automated periodic scanning of your own site(s). If you
> expect to get an "A" rating and one day you aren't "A" quality any
> more, you should get an alarm without having to remember to
> manually-run the web-based tool when you get around to doing it.

And of course, such a thing already exists:
https://www.unixadm.org/nagios/check_sslscan

This tool uses SSLLabs's online tool so it would be subject to the
same restrictions as the web-based version (e.g. no internal hosts).

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAleI6bYACgkQ9CaO5/Lv0PDDlgCgprkU2h++wmgOafv+mYsTwZOr
iikAnRyy1gBncREDypbnvb7sk27fypid
=Q6bW
-END PGP SIGNATURE-

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

Re: SSL/TLS and ciphers vulnerability

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 7/14/16 4:14 PM, Mark Thomas wrote:
> On 14/07/2016 19:36, uzair rashid wrote:
>> Jeffrey,
>> 
>> Working for a corporation that has strict ssl and security
>> requirements.. There is no way to use the tools you suggested,
>> since the tomcat URLs are not exposed.
> 
> That doesn't stop you setting up a stand-alone test instance using
> the same settings (with a different cert if you are especially
> paranoid) and checking those settings using the excellent ssllabs.
> 
> Keeping your Tomcat and JVM versions up to date will also help.
> The Tomcat team periodically reviews Tomcat's default TLS
> configuration and adjusts it accordingly. For details of the most
> recent review see: https://wiki.apache.org/tomcat/Security/Ciphers

A few thoughts:

1. Since Tomcat can take OpenSSL-style cipher suites configuration, is
there a way to ask Tomcat to take an OpenSSL 'ciphers' specification
and have it emit the JSSE equivalent? I know Tomcat does this
internally, but can it dump the configuration for debugging purposes?

2. The OpenSSL ciphers specs on the "Ciphers" page above only includes
"HIGH" ciphers which is appropriate for today's safety, but it doesn't
prioritize them in any particular way. This may be the default for
OpenSSL, but I typically prioritize ECDHE and ECDH ciphers before the
other ones in the HIGH category.

3. There's usually no reason to include the "PSK" (pre-shared key)
ciphers in your server's cipher spec, so I always disable those as well.

4. It's fairly important to enable "server-order" cipher suite
selection, so that the server's preferences are used over the client's
preferences, in case you have a lay client who would choose a trivial
cipher if it were available. This is, for example, how older versions
of MSIE behave: they REALLY prefer to use cipher suites using RC4 even
if higher-grade ones are available. Of course, you should really
disable cipher suites you aren't willing to use, but sometimes you
just HAVE to include some really bad ciphers in the list in order to
support super-old clients.

5. Many people don't know about the "Unlimited Strength Policy Files".
I've been thinking that we might want to issue an INFO message at
startup if TLS/JSSE is in use and the "Unlimited Strength Policy
Files" aren't available. This may encourage more people to install
them. Unfortunately, I don't know if a way to install those files
without modifying the JRE being used to launch the JVM. If anyone
knows how they can be installed just for one application (Tomcat), it
would be nice to provide a guide for how to do that.

6. Qualys has a tool called ssllabs-scan available on GitHub:
https://github.com/ssllabs/ssllabs-scan/

I haven't read-through the code yet, but I suspect it's a copy of the
whole scanner and doesn't "phone home" (except maybe to grab the
latest configuration and scoring rules). This may make it possible to
scan some of those internal servers that aren't facing the public
Internet (and therefore can't be scanned directly using ssllabs
web-based tool). It may also speed-up the scanning of a site, since
their web-based tool is throttled to avoid using it as a DOS tool.

The existence of the ssllabs-scan tool means it's also possible to
set-up automated periodic scanning of your own site(s). If you expect
to get an "A" rating and one day you aren't "A" quality any more, you
should get an alarm without having to remember to manually-run the
web-based tool when you get around to doing it.

Have fun. Be safe.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAleIOuoACgkQ9CaO5/Lv0PC5qACgv3S3g507PqlkzU3kDpVH3WJw
zlYAnjXP/nvFpvnKPG4XPlMLOgqEzjrk
=hb5i
-END PGP SIGNATURE-

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

Re: SSL inconsistency

[Mark Thomas]

On 14/07/2016 15:09, i...@flyingfischer.ch wrote:
> While testing locally the new 8.5 branch, I did experience some
> inconsistency with self-sigend SSL certs. I did manage to resolve them
> by installing Tomcat-Native library / APR, but maybe it is still worth
> reporting in regard of the different behaviour for the same cert,
> between Tomcat versions and configuartions.
> 
> I didn't want to file a bug, since this very likely is a configuration
> and/or self-signed cert problem.
> 
> Thanks for considering.
> 
> Markus
> 
> Tomcat 8, works fine.
> Tomcat 8.5  error => Alias name tomcat does not identify a key entry
> 
> URIEncoding="UTF-8"
>clientAuth="false"
>keystoreType="PKCS12"
>keystoreFile="[path-to]/localhost.p12"
>keystorePass="tomcat"
>maxThreads="150"
>port="8443"
>protocol="HTTP/1.1"
>scheme="https"
>secure="true"
>sslProtocol="TLS"/>
> 
> ---
> 
> Tomcat 8.5, same cert, starts fine but throws on first SSL invocation:
> 
> java.lang.IllegalArgumentException: Invalid character found in method
> name. HTTP method names must be tokens
> 
>  sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
>port="8443"
>URIEncoding="UTF-8"
>clientAuth="false"
>keystoreType="PKCS12"
>keystoreFile="[path-to]/localhost.p12"
>keystorePass="tomcat"
>maxThreads="150"
>scheme="https"
>secure="true"
>sslProtocol="TLS" />

Entirely expected. You haven't set SSLEnabled="true" so the connector is
expecting HTTP, not HTTPS.

> Tomcat 8.5, new cert
> Tomcat-Native / APR disabled
> 
> Failed to initialize end point associated with ProtocolHandler
> ["https-jsse-nio-8443"]
> java.security.KeyStoreException: Cannot store non-PrivateKeys
> 
> Same cert works with Tomcat-Native / APR enabled
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>maxThreads="150" secure="true" scheme="https"
> SSLEnabled="true" defaultSSLHostConfigName="localhost">
> 
>   certificateFile="[path-to]/localhost.crt"
>  type="RSA" />
> 
> 

You don't say which 8.5.x version. While I can't repeat this exact
error, I can create a similar problem with 8.5.4 where PEM files (ie the
standard OpenSSL format) does not work with a JSSE connector.

I've fixed this issue for 8.5.5


> Also works with protocol="org.apache.coyote.http11.Http11AprProtocol"
> with Tomcat-Native / APR enabled

That appears to confirm that it was the PEM -> JSSE conversion was
broken since that is not required for APR/native.

Mark

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

Re: SSL/TLS and ciphers vulnerability

[Mark Thomas]

On 14/07/2016 19:36, uzair rashid wrote:
> Jeffrey,
> 
> Working for a corporation that has strict ssl and security requirements..
> There is no way to use the tools you suggested, since the tomcat URLs are
> not exposed.

That doesn't stop you setting up a stand-alone test instance using the
same settings (with a different cert if you are especially paranoid) and
checking those settings using the excellent ssllabs.

Keeping your Tomcat and JVM versions up to date will also help. The
Tomcat team periodically reviews Tomcat's default TLS configuration and
adjusts it accordingly.
For details of the most recent review see:
https://wiki.apache.org/tomcat/Security/Ciphers

Mark

> 
> On Thu, Jul 14, 2016 at 8:41 AM, Jeffrey Janner > wrote:
> 
>> Hi folks,
>>
>> I've been off the list for a bit, getting ducks in a row here and
>> everything.
>> I noticed a number of posts about SSL & TLS security settings lately and I
>> wanted to point out that maintaining your SSL configurations is an on-going
>> processes.
>> New exploits are discovered and released quite often, and often the fault
>> lies with a cipher and not necessarily an overall SSL/TLS protocol.
>> So using a cipher list like "all except RC4" is probably not sufficient
>> anymore.
>> And what is secure may depend completely on the SSL/TLS software you use,
>> be it OpenSSL or Java's built in SSL libraries.
>> For example, with OpenSSL, you should be using 1.0.1t or higher, and even
>> then only TLS1.2 with a handful of ciphers.
>> I'm not sure what the recommended options for java's libraries are at the
>> moment.
>> A really good, free tool is Qualys' SSL Labs server test tool located at:
>> https://www.ssllabs.com/ssltest/
>> Run that against your implementation and follow its recommendations.
>>
>> Of course, at the end of the day, it will be up to you and your firm to
>> decide what risks you are willing to take with your SSL communications and
>> whether or not you need to support insecure browsers, i.e. browsers that
>> cannot negotiate up to the most secure protocol and ciphers.
>>
>> Jeffrey Janner
>> p.s. Qualys also has a test suite for the browsers that you use.
>>
>>
> 


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