Re: Trouble with TLS/SSL and Tomcat 8.5.23
On 23 November 2017 at 17:20, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Richard, > > On 11/23/17 8:28 AM, Richard Tearle wrote: >> Yes I read through that thread, but we don't really like Java key >> stores, and I don't think the work around would work for us. > > Java keystores are ... awful. > >> Instead, I did what perhaps I should have done a while ago (on >> version 8.0.x), and built Tomcat Native libraries, deployed, and >> changed the certificate references in the connector to use our .PEM >> files (which the PKCS12 files are built from), and fingers crossed, >> its looking OK at the moment. > > So are you using the APR connector, then? > > You do have some other options: > > 1. JSSE with a PKCS12 keystore. OpenSSL can work with those types of > keystores. > > 2. JSSE with PEM-encoded DER files. I prefer PEM-encoded DER files for > everything, simply because they are so easy to work with. > > 3. JSSE+OpenSSL with PEM-encoded DER files. > > Option #3 will get you the performance of OpenSSL's crypto but without > using the APR connector (which isn't quite as efficient as the > pure-Java NIO connector). Java's crypto seems to be hobbled for some > reason... some kind of mistake in the native-optimization that ends up > falling-back to pure-Java crypto which ... simply isn't fast enough > for real-world workloads). > > I think the APR connector is likely to disappear with the next major > release of Tomcat (10.x I would guess) as the NIO+OpenSSL combination > is becoming more mature and offers better performance and scalability. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloXA2AACgkQHPApP6U8 > pFilzA/9E5R4NjcoB1yE6oQ2sXb7TURJg/WDJls00Y7RjwSN1UmkiiAdwktcuH0T > hL6+2M71yrJ+rnCLbyQGEmPdJdFSAv4rTy+eoHJqDTf9jakUYvLC+XvIdWgz/p6i > tWhIRZAS/sr4JmwFgrIY4I4iKcmJ/pGjrQHLu59H0gEYFdOCoA+WpsNgmIiFLUr6 > IWochlde/ahxP6vNOZJLYxBb8kQ8JUBWXHN+2jGiD5GU7jav3DmwlFKeaoelbclk > DUUbzc+no83pSIcwzsNsIcPjxdh9fSIzP3nAdNDlIJtGF3SDwwu6HyP0cEb+r+rg > l9LjDwUrcIFB7pAas38bUpf8DjSysRLk5Jh013BhxUJIcB5hZflrUqeq6Nb+JonC > EepZoUNSWFiblB36ofNmyJUXaRshBqVfD/x1teJXpoLVJ/HUY8A84T3DlLIzHMAS > lMfJ4CaCYyDqeA5KL9PZMyEpiPivn4aqeMeVEkrz/DHamLvWhJ649mfRb9BNOBE0 > 3uJvLHOYanORuVWAyQc6nmpSFuda3lgUCZVN9/jhRNW6AszBjLi/9xb7vP/EE41I > jXZYnJgra1tdL2wq85cqR3NRIf2HrZrvaVsQOikn+MqHR19Pwm5T3xrlIN9hT4EP > t9LeqizK0vK0cz0/tDBVmqXjASyP5ArJ0dz6uJqijJtGjUWe+gM= > =bf9o > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Hi I think Option #1 was what I was trying to achieve originally. I'll take a look at option #3 tomorrow. Thanks for the heads up Richard. -- 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: Trouble with TLS/SSL and Tomcat 8.5.23
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Richard, On 11/23/17 8:28 AM, Richard Tearle wrote: > Yes I read through that thread, but we don't really like Java key > stores, and I don't think the work around would work for us. Java keystores are ... awful. > Instead, I did what perhaps I should have done a while ago (on > version 8.0.x), and built Tomcat Native libraries, deployed, and > changed the certificate references in the connector to use our .PEM > files (which the PKCS12 files are built from), and fingers crossed, > its looking OK at the moment. So are you using the APR connector, then? You do have some other options: 1. JSSE with a PKCS12 keystore. OpenSSL can work with those types of keystores. 2. JSSE with PEM-encoded DER files. I prefer PEM-encoded DER files for everything, simply because they are so easy to work with. 3. JSSE+OpenSSL with PEM-encoded DER files. Option #3 will get you the performance of OpenSSL's crypto but without using the APR connector (which isn't quite as efficient as the pure-Java NIO connector). Java's crypto seems to be hobbled for some reason... some kind of mistake in the native-optimization that ends up falling-back to pure-Java crypto which ... simply isn't fast enough for real-world workloads). I think the APR connector is likely to disappear with the next major release of Tomcat (10.x I would guess) as the NIO+OpenSSL combination is becoming more mature and offers better performance and scalability. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloXA2AACgkQHPApP6U8 pFilzA/9E5R4NjcoB1yE6oQ2sXb7TURJg/WDJls00Y7RjwSN1UmkiiAdwktcuH0T hL6+2M71yrJ+rnCLbyQGEmPdJdFSAv4rTy+eoHJqDTf9jakUYvLC+XvIdWgz/p6i tWhIRZAS/sr4JmwFgrIY4I4iKcmJ/pGjrQHLu59H0gEYFdOCoA+WpsNgmIiFLUr6 IWochlde/ahxP6vNOZJLYxBb8kQ8JUBWXHN+2jGiD5GU7jav3DmwlFKeaoelbclk DUUbzc+no83pSIcwzsNsIcPjxdh9fSIzP3nAdNDlIJtGF3SDwwu6HyP0cEb+r+rg l9LjDwUrcIFB7pAas38bUpf8DjSysRLk5Jh013BhxUJIcB5hZflrUqeq6Nb+JonC EepZoUNSWFiblB36ofNmyJUXaRshBqVfD/x1teJXpoLVJ/HUY8A84T3DlLIzHMAS lMfJ4CaCYyDqeA5KL9PZMyEpiPivn4aqeMeVEkrz/DHamLvWhJ649mfRb9BNOBE0 3uJvLHOYanORuVWAyQc6nmpSFuda3lgUCZVN9/jhRNW6AszBjLi/9xb7vP/EE41I jXZYnJgra1tdL2wq85cqR3NRIf2HrZrvaVsQOikn+MqHR19Pwm5T3xrlIN9hT4EP t9LeqizK0vK0cz0/tDBVmqXjASyP5ArJ0dz6uJqijJtGjUWe+gM= =bf9o -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: encrypting passwords in tomcat-users.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Guy, On 11/22/17 1:50 PM, Guy wrote: > Maybe I should ask this in a different way: what are the steps to > use encrypted passwords in tomcat-users.xml under Tomcat 8.0.14? Note that the passwords aren't "encrypted" per se (that is, they are not using reversible encryption), but they have been modified such that they cannot be recovered. This is known as a "secure hash" -- even when it's more complicated than that ... such as using PBKDF2, bcrypt, etc. They are essentially the same basic idea, but the PBKDF2s of the world add a bunch of other features to strengthen the key and add complexity to the process to yield a higher-quality stored credential (the thing that you put into the tomcat-users.xml file). > I know what they are in Tomcat 8.0.37. They're both versions of > Tomcat 8.0.x, so why does something that works in one not work in > the other? Does the server.xml configuration need to be different? That depends upon what you want to do. > Here are some specifics on how I'm running digest.sh. > > As you will see, they are different. The newer version has more > arguments, and produces a different output, in the format > salt$iterations$digest. Yes. This reflects the current default operation of digest.sh, but the credential handlers ought to be backward-compatible so if you use a digest with no salt and no iteration count, the newer version of Tomcat should be able to use it without a problem. A salted, iterated hash is more secure than one that isn't, which is why the default operation has been changed. > First, on Mac with apache-tomcat-8.0.37: > > % ./digest.sh secret > secret:304fb189dd47d028f892f95a0d9a2c8d707b24d72474b62e78d30401a7cc05b 6$1$a299b9b24fdaf7219500ad39f21cea319fdce2a99d175c263ab16bd89c428ffdbafe a125f9559a4be9081b5955c35574dae002fb2b32b1acccdef9c77a81fb2e The > version of Tomcat is significant, but the OS is not. This isn't a Mac-vs-Linux thing. > % ./digest.sh Usage: RealmBase [-a ] [-e ] [-i > ] [-s ] [-k ] [-h > ] > > I believe this is defaulting to SHA-512 as per the docs and the > fact that it worked when I configured the Realm to use SHA-512 with > the CredentialHandler. Right. > Next, on Linux with apache-tomcat-8.0.14-1: > > # ./digest.sh secret Usage: RealmBase -a [-e > ] # ./digest.sh -a SHA-512 secret > secret:bd2b1aaf7ef4f09be9f52ce2d8d599674d81aa9d6a4421696dc4d93dd0619d6 82ce56b4d64a9ef097761ced99e0f67265b5f76085e5b0ee7ca4696b2ad6fe2b2 > > > > So, something in the underlying RealmBase class is different, and > I can't get this output (or anything) to work on this server. > There's also a warning in the log: > > org.apache.tomcat.util.digester.Digester.endElement No rules > found matching > 'Server/Service/Engine/Realm/Realm/CredentialHandler'. > > which leads me to believe the server.xml configuration needs to be > different for this version too. However, none of this is indicated > in the documentation. I'm at a complete loss. Pluggable CredentialHandlers (and the significant upgrades to the authentication system including support for salts and iterations for "basic" crypto hashes) weren't added until Tomcat 8.0.15 [1], so you won't be able to use those. If you need to be able to use the same configuration for both Tomcat 8.0.14 and Tomcat 8.0.37, then you'll need to use the non-salted non-iterated hashes supported by the older version. If you want to be able to generate those hashes with Tomcat 8.0.37 and use them with Tomcat 8.0.14, then you'll need to use some more command-like arguments to generate a backward-compatible hash: $ ./digest.sh -s 0 -i 1 secret secret:bd2b1aaf7ef4f09be9f52ce2d8d599674d81aa9d6a4421696dc4d93dd0619d682 ce56b4d64a9ef097761ced99e0f67265b5f76085e5b0ee7ca4696b2ad6fe2b2 If you set the salt-length to zero (bytes) and the iteration count to 1, you'll get a hash that matches what Tomcat 8.0.14 would have produced . Hope that helps, - -chris [1] http://tomcat.apache.org/tomcat-8.0-doc/changelog.html#Tomcat_8.0.15_(ma rkt) -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloW/4YACgkQHPApP6U8 pFhFtA/7BIJRqXRoc63Wn172BbcNvdp9ox2sJvB/PvSGObYKrpSjhg3gAYaVYUWc IBDUH0oBG8d7RN1evSKDr1sMtqc5o0k1JJAxkNuUh1Dn1C2oCkuKw6e9XBZxu71S Wkpskh3gHOrgEY6LLE2ui6ISDpAMU07+fl/Mu6bIUz7cI806MlAKmgLjCZRPTP5X ol46NFDPz1B9CuC4Mfw6lmOlGASvKrNIfrBKA7fRh78tm4ZG7pLC4m0Ejl1QU/0S 0qHTmoTb78056QZKuVvKUPTzZSXa0WxxUZcjH7yX0XPGmgUwPzQbgvkc9tPgt/vo bvUAudNlTdEKpHCFr5wugvdLH4YdcNqi/yIzdHEOdgh0+JSO0O+8PRBmoOpejmxo w8UnTOXe8dcKbUnynKJrFKDBk36hqEZkSde9Cnki4MLmDTjRAZ4t+0Dbo6SaZAQp OFir+4uM0JGfEG5b/AwK4yI4hIZ12JO9BDob7BLaTkIWHKVSBNL3IVg7RUOH0mKZ C1W+HeS0aLbZF4S9WJ5IEbefWQ7ORZk5TtwUfM04+sPJs0PIRpo4yXkzAYC7AqOp N7f4h1xa18puo6dm3rFzznmplYqchvuQLuGzas+7hrgZZBOCSXHGe7+oceso0U7N dClxSowtGRzrWTd8g+djyfTOXyvxTibjdd+2NxIhQm5dYynoulA= =gxmP -END PGP SIGNATURE- -
Re: Trouble with TLS/SSL and Tomcat 8.5.23
On 23 November 2017 at 05:33, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 11/22/17 8:40 AM, Richard Tearle wrote:
>> Hello
>>
>> Apache Tomcat 8.5.23 Centos 7.4 (3.10.0-514.16.1.el7.x86_64) Java
>> 1.8.0_152 (with jce) Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to
>> 8.5.23, but when trying to get TLS/SSL working on a connector I get
>> the following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end
>> point associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:115)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
> seEndpoint.java:86)
>> at
>> org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:9
> 82)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
> int.java:245)
>>
>>
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> tocol.java:66)
>>
>>
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
> 97)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.ja
> va: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:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644) at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
>>
>>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty at
>> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
> 200)
>>
>>
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
> java:130)
>>
>>
> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:
> 368)
>> at
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
> a:292)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstrac
> tJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not
>> exact issues, and going back to 8.5.4 "solved" the issue. So I did
>> this as a quick test, so at least I could see that our
>> configuration changes where correct, and yes the application ran ok
>> with Tomcat 8.5.4. The connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>> server="Apache" maxPostSize="10"> > certificateVerification="none" sslProtocol="TLSv1.2"
>> protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12" truststorePassword="${truststore.pass}"
>> honorCipherOrder="true"
>> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AE
> S_256_GCM_SHA384,
>>
>>
>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_S
> HA384,
>>
>>
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM
> _SHA256,
>>
>>
>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_S
> HA256,
>>
>>
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC
> _SHA384,
>>
>>
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SH
> A,
>>
>>
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_S
> HA384,
>>
>>
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
>>
>>
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC
> _SHA256,
>>
>>
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SH
> A,
>>
>>
>> TLS_
Unable to use Tomcat JDBC CP with XA connections
Hello, I have Tomcat 8.5.23 with following context.xml: It declares XADataSource using Tomcat JDBC CP. When I retrieve a connection I get the following exception: org.postgresql.util.PSQLException: Connection has been closed. If I declare connection without Tomcat CP it works ok: Do I have any errors in my configuration? I prepared a simple demo app on github for problem demonstration: https://github.com/Speedbird/ds-test To reproduce problem run: "mvn clean package && docker-compose up" Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
