OS
Hello, I am doing an investigation. Does Windows Server 2019 support the following products: Apache Tomcat 6.0.35 Tomcat Connectors (mod_jk) 1.2.35-m1.0 Is the other version supported? Can you tell me, thank you very much.
Using custom Configurator with WebSockets
Hello,
Just a quick question with regard to extending
ServerEndpointConfig.Configurator to override Tomcat's default action of
instantiating the POJO class annotated with @ServerEndpoint on receiving a
WebSocket request. My reason for doing this is that my endpoint class
depends on IoC dependency injection, and therefore needs to be got from
the registry to have its dependencies in place.
My Configurator method:
@Override
public T getEndpointInstance(Class endpointClass) throws
InstantiationException {
return
endpointClass.cast(RegistryProxy.getService(HarbourServerEndpoint.class));
}
The @ServerEndpoint annotation is placed on on my
HarbourServerEndpointImpl POJO class, not the interface that it
implements. Based on the below runtime catalina.out error message the
problem appears to be that the registry is returning HarbourServerEndpoint
whereas Tomcat is expecting an instance of HarbourServerEndpointImpl?
I'm hoping someone can please explain what is going wrong with my custom
Configurator.
15-Apr-2019 12:45:28.488 SEVERE [http-nio-8080-exec-915]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading
request, ignored
java.lang.ClassCastException: Cannot cast
$HarbourServerEndpoint_39c9cc24eb8b2a to
com.optomus.harbour.services.HarbourServerEndpointImpl
at java.lang.Class.cast(Class.java:3369)
at
com.optomus.harbour.services.HarbourServerEndpointConfigurator.getEndpointInstance(HarbourServerEndpointConfigurator.java:17)
at
org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:44)
at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:133)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:846)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Finally, with no casting at all, the compiler gives the error:
Error:(17, 40) java: incompatible types: inference variable T has
incompatible bounds
equality constraints:
com.optomus.harbour.services.HarbourServerEndpoint
upper bounds: T,java.lang.Object
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wildcard certificates
Exactly .. this is part of the solution. I am having tomcat behave smartly in response to the certificate validation, and I have a nice path to develop some cool tools, similar to HTTPD, around certbot (I love that this is a free service, but I do have some concerns over centralized CSA, so I do other symmetric key encryption in other areas to help me sleep at night). On 4/17/19, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > To whom it may concern, > > On 4/17/19 09:44, TurboChargedDad . wrote: >> We terminated SSL above the tomcat layer using NGINX or Apache to >> avoid the complexities that come with managing a JKS. I want to >> hear all I can on this subject. > > It's not necessary to handle JKS files to use Tomcat for TLS termination > . > > You can use PEM-encoded DER files (same as httpd, nginx, etc.) if you > use any connector along with the OpenSSL engine. > > You can also use PKCS12 files (similar to JKS files, but much more > standard) which openssl knows how to manipulate (as does Java's > "keytool") with any JSSE-based crypto engine. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly3VzcACgkQHPApP6U8 > pFhOwxAAtd5d0UDSp1SEjZWKu+AX970vUTZIc+UxeWAWcwG20MjBeHa4PBzrJFIK > QVduzNGBJvi2oez9QV3LCnLo2jkIgpZG6EC/+TBQSSfAn8iGrL7lc59vWXg551PC > 8+llFd9q3M13dqyx824YijMPptwFxH36z0K2pr34ytZOP1g/QDUA07dW5rW2rJKF > tdOkHIE/QvEE+iSQnrYQbNNknBk/grzbxDwg7lZupSi1UBY080Hc8aPzWknBADKh > zPKt6942WMvrIDmK8yCQSgkqjG8QWrZfR5QNkvnkRN4rridK4TevYm6Da/QI46w3 > NPSozJeNKGeaUylabH4jTcVBE3eynOcP0oyBJ7/MmMzu1a9jU9ar7mZmTlZEPaEV > f3jxmfQ5m4AmbypNfwLzudo0ekVQceD33Ba04/VO9wGESMNSQTF6XIz69BSHvj1s > KsIIFcgdWuVH5ae5UxgirWghecz2xZAu7BHXYtkPdLcmF/RgTR1lQQ34JDlB9VPM > NdtZuVUWasnlWVGF4YDV6RzQwdhzGk4FUd38ULRzsc+ycyA0LtbdQfyear/N/dxl > c4s+nPiub1lnggMbd990uPMhoy8AaEGq4GG6NyKXvBz1sUw72n27QO6tCEIinQSe > E8OOofUgHAcLwuEQxLO/bvVnD77Vx95lxnIoludx51BvEM1ZbbU= > =M18j > -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: Wildcard certificates
On 4/17/19, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > On 4/17/19 10:42, John Dale wrote: >> My understanding is that the folks at SUN really put their backs >> into it from the beginning: >> https://stackoverflow.com/questions/479701/does-java-have-buffer-overf > lows >> >> Since hot spot compilers have matured, Java is virtually as fast >> as C/++ (the Java is slow argument falls in my deaf ears, even if >> it is amazingly repeated still today by members of other >> programming religions). > > Where it really sucks, though, is crypto. When JSSE decides to use > hardware for crypto, things go really well. But it often does not make > that decision due to a few bugs here and there that still appear to > remain in the runtime. > > Tomcat benchmarks comparing JSSE versus OpenSSL are at least an order > of magnitude different, sometimes two, in favor of OpenSSL. > > Have a look at any of the slides Jean-Frederic Clere has presented at > any recent ApacheCon conferences and you can see his benchmarks > comparing them. > > The good news is that Tomcat+OpenSSL is comparable to httpd+OpenSSL, > so if you are able to use tcnative (required for OpenSSL use from > Tomcat), then the performance argument is pretty much moot. > > I myself always front Tomcat with another web server, but that is for > other reasons. Security and performance are nice-to-haves but aren't > really justified IMHO. Flexibility is the primary reason I front my > Tomcat instances with web servers. Tomcat doesn't make a great > load-balancer. > > - -chris You mean on its own without modification? I think Tomcat makes a great load balancer, but I had to write a little code. HTTPD has a lot of plugins and ad-ons and a history of integration with lots of tools from firewall to email and beyond. It's a crazy piece of software that is very mature, but I found it to be overkill for my purposes .. I just use LFD/CFS manually, and I will continue to improve my DDOS, other exploit mitigation code. > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly3WdkACgkQHPApP6U8 > pFiRrg//QcXdcysOx18yEpadFhuUekcTvogC5BGhZe5lV3AY4fgXeXQH46YZOkeY > Lit5F6JRFb9qVwFs9Uc9Ot9hwvVt9ldFMKOKAkxMIAp1yxRk8sWuaI99OLiNBAyf > qKmfwI0bx4H73oR22jhP5mlIITzJShZc86R9apb/v34ofncxQ6bLlAQMxu98Wo7W > G4kBXTjnn7UzNFtpAXiZLd8t22IeBbN6CDFgM5urhOb3g7rTNdqW8Q28ik7qwenK > gK5KmSek7+LZTsx5UD3N4WxdRkUKB30ZIvPt+cH1HMntvulQKJ39Giw9XjXHv8Hc > VIsrh/S+2fbfG+4F0aqYmR5WuEXK30mG76DU3DW2o3v8sZ+pvuJ3C37mc0biWGy7 > fS722Uh3s6tucs4ToQtwwYkhS93NIUm8uLZJnv3FAUW5EOY7THzf0pplv/ZZEQ62 > Sg1bZ4mA7/Tdt25MKM2K04h2ERLTsAiB7Qneh2Ch4yVt3cwnGbZUFCAbXMSq01xE > TP6j0zfLAtEx3b6Av22WLqnq5NdSDUYbvVzTQPH/TUERf4ztLRadBjHPEN0gM2vL > zQi7BGiJix2K/fjWLicGkZKTPCWvSnknkwPgQ1JzxZwEQmCUA+hRANaZljp7KVwP > mObnaRL5QQ/S2NhCRHFdvyLqXMgmbSsMe+FMmN2P8/mADwSdeK8= > =4xik > -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: Wildcard certificates
I manage dozens of contexts/domains using loosely coupled code. Chris - of course it's amazing. I would also call it super and profound. :) I am in the middle of some TI at our office today .. can't really stop to do this. I have the code used to identify and validate the certbot requests and a few scripts that use the certbot to do the work. Come to think of it, my certs will need renewal soon. I'll take a pass over what I have and send it out after I renew .. thank you for your patience. John On 4/17/19, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > To whom it may concern, > > On 4/17/19 10:22, TurboChargedDad . wrote: >> I would have the opposite feeling. I would not want a java process >> parked out in the internet. Not saying you're wrong just my >> personal feeling. > It would be interesting to compare the number of remotely-exploitable > vulnerabilities there have been in e.g. httpd versus e.g. Tomcat in a > given period of time. My guess is that the Java-based servers have had > a better track record. The difference is that typically if you own a > web server, you just own the web server. But if you own an application > server, you typically get access to lots of great stuff like the > application's database. > >> Maybe things have shifted in a different direction over the year. > Any particular year? > >> I do agree that something like that would be helpful to other >> tomcat admins. Would you consider putting it into github ? > certbot does almost everything you need. There is also this: > https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encrypt > %20Apache%20Tomcat.pdf > > So unless John has done something truly amazing, maybe adding more > tools to what MUST be a secure toolchain isn't a great move. > > - -chris > >> On Wed, Apr 17, 2019 at 9:18 AM John Dale >> wrote: >> >>> I have a really nice process that works great with certbot. >>> Single command to renew all of my certs and I'm finished. >>> >>> I get some piece of mind having a Java process guarding the >>> front door. Seems to be more impervious to overflows. What am I >>> missing? >>> >>> I think what I have might be easily developed into something to >>> help other Tomcat users. >>> >>> On 4/17/19, TurboChargedDad . wrote: We terminated SSL above the tomcat layer using NGINX or Apache to avoid the complexities that come with managing a JKS. I want to hear all I can on this subject. >>> >>> - >>> >>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly3WFMACgkQHPApP6U8 > pFjFUA//Q5HiqvarK/NO/o2tjtVUVs75RJaTEao7T1eUCwMIf/F9nkpZpNG8TxK7 > slT0zu3GMaB5+Z5PK753M3+vZ9nytbat4ODbUNpUMrqeT1/U0eaF1LdbY0jeUmKH > hmzQFTtLEtJ9mMYn+KJ3sA8D3sIECWwFuKD+BdYmOkzAZn37HlzyI+1CMr4mEA6C > LnhlD/hEeG4HiO5FtE4BxRKZ0vcLhBp10/m27E6j6KDiiwT7+tlNfwD53S5P94vv > f/FbwSP8GJfkFu13ot+ce1IVerMNpMpc6nay1efJmYtT4oHyNP0YUVMZyN8YyCTO > 5yiLYOj8yXLxLatdKBWJ+1fsqd5DXuOEv0KmaIaqi3pLHg5oJQp5CtsLKTSFVTmV > FBoWew1JFhh5DBI27uJntGzlwIGjKAq7Cq0qitL2gVCiDr6HFaI/gkvVriDjoZL/ > L3E5JDSpYL/iSzBeBd5qKbGVz7+/bdsHoxdHGRFrvcNYyPZIT871bVoNjvyaSFsM > KZGYcgZgruzN6hT3+jmJpHHoINb+XQeViM140HvYJP1zrcyCZ9ejqpw1BSB+WbT0 > OutjYugoJwORD2SWFTXAc5g6flP5I6JYogexzlj0UPx6v0969I6OBPkLRyMzyKnr > RTSLV2mYJifNFjLvJ98blhhRmZG3BgAJR4ussur1NTZzs6I03Bc= > =4l6s > -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: how to enable OCSP for Tomcat w OpenSSL
I'm still struggling with getting APR/OpenSSL to do the OCSP check. I'd appreciate some tips: versions: Java 8 (1.8.0_202), 64-bit, tomcat 8.5.38, APR 1.2.21 using APR/OpenSSL (the tc-native-1.dll binary for Windows, compiled w OCSP support - the X64 dll from tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip) I can't get certificate revocation checking, specifically OCSP to happen from the APR/OpenSSL code; it seems to be happening instead from the Java (JSSE) code instead. I suspect a logic error is setting the OpenSSL revocation configuration (callback?) code to be set, then reset with the JSSE revocation configuration (due to the Catlina log excerpts shown below). I've tried following the APR initialization logic in the tomcat 8.5.35 source, (but I get lost)... OpenSSLContext.java has SSLContext.setCertVerifyCallback() I suspect this is getting called correctly, then getting stepped on by the JSSE configuration being called (when it should be skipped). But I may just have something misconfigured. steps to reproduce: First, get Java revocation checking working without tc-native: UNcomment ocsp.enable=true in the Java\jre\lib\security\java.security file add revocationEnabled="true" certificateVerification="require" to the SSLHostConfig / Connector section of the server.xml config file. add -Djava.security.debug="certpath" to the Tomcat Java options (shows the JSSE cert validation - including OCSP if any - in the std-err log) or -Djava.security.debug="certpath ocsp" (adds hexdumps of the OCSP REQUEST and RESPONSE. Generally not needed) (add -Djavax.net.ssl.trustStore=NONE to prevent the default truststore from being loaded - just because it clutters the std-out log) added to loggin.properties to see some of what Tomcat is logging: org.apache.tomcat.util.net.openssl.level=ALL org.apache.tomcat.util.net.level=ALL org.apache.tomcat.jni.level=ALL Restart tomcat, access via a browser with an appropriate cert (or OpenSSL or other client with options to send a client cert). You now can see JSSE doing OCSP checks in the (tocat)stderr logs (wireshark confirms this). stop tomcat, copy the tc-native-1.dll compiled with OCSP support, restart tomcat... access via browser (or client) with a cert etc... You'll see the tomcat stderr logs show that JSSE is STILL doing the OCSP checks. Catalina and stdout logs show that APR/OpenSSL is loading the server and trusted certs, doing the SSL handshakes etc, but not the certificate verification. this seems to be falling through to the JSSE certificate verification.. (and that JSSE is ALSO loading the trusted certs (and the server cert, I think). the Catlina log shows that the APR/OpenSSL stuff is loading and configuring properly first: org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache Tomcat Native library [1.2.21] using APR version [1.6.5]. org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1a 20 Nov 2018] org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol The ["https-openssl-nio2-A.B.C.D-443"] connector has been configured to support negotiation to [h2] via ALPN org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-openssl-nio2-A.B.C.D-443"] org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [protocols] that are active are : [[TLSv1.3, TLSv1.2]] org.apache.tomcat.util.net.openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE jsse.openssl.effectiveCiphers org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are active are : [[TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_256_CCM, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 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_SHA, TLS_PSK_DHE_WITH_AES_256_CCM_8, TLS_DHE_PSK_WITH_AES_256_CCM, TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_WITH_AES_256_CBC_SHA, TLS_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_AES_256_CBC_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
Re: Is there a problem with the digest?
Nothing changed since before your server crashed to after, and I've checked all junk and spam filters. I am still not receiving any of the digests anymore. Are the digests even being sent out? Thanks, -R On 12/04/2019 16:32, Mark Thomas wrote: > On 12/04/2019 16:29, Mark Thomas wrote: >> Which address did you use to subscribe to the digest list? It wasn't >> this one... > > Ignore that. ezmlm cmd line error on my part. I see your digest > subscription in the logs from this address. Hmmm. > > Let me go and dig into the mail logs... Nothing obvious. And my test digest subscription is working. Are you still having issues? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Wildcard certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 4/17/19 10:42, John Dale wrote: > My understanding is that the folks at SUN really put their backs > into it from the beginning: > https://stackoverflow.com/questions/479701/does-java-have-buffer-overf lows > > Since hot spot compilers have matured, Java is virtually as fast > as C/++ (the Java is slow argument falls in my deaf ears, even if > it is amazingly repeated still today by members of other > programming religions). Where it really sucks, though, is crypto. When JSSE decides to use hardware for crypto, things go really well. But it often does not make that decision due to a few bugs here and there that still appear to remain in the runtime. Tomcat benchmarks comparing JSSE versus OpenSSL are at least an order of magnitude different, sometimes two, in favor of OpenSSL. Have a look at any of the slides Jean-Frederic Clere has presented at any recent ApacheCon conferences and you can see his benchmarks comparing them. The good news is that Tomcat+OpenSSL is comparable to httpd+OpenSSL, so if you are able to use tcnative (required for OpenSSL use from Tomcat), then the performance argument is pretty much moot. I myself always front Tomcat with another web server, but that is for other reasons. Security and performance are nice-to-haves but aren't really justified IMHO. Flexibility is the primary reason I front my Tomcat instances with web servers. Tomcat doesn't make a great load-balancer. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly3WdkACgkQHPApP6U8 pFiRrg//QcXdcysOx18yEpadFhuUekcTvogC5BGhZe5lV3AY4fgXeXQH46YZOkeY Lit5F6JRFb9qVwFs9Uc9Ot9hwvVt9ldFMKOKAkxMIAp1yxRk8sWuaI99OLiNBAyf qKmfwI0bx4H73oR22jhP5mlIITzJShZc86R9apb/v34ofncxQ6bLlAQMxu98Wo7W G4kBXTjnn7UzNFtpAXiZLd8t22IeBbN6CDFgM5urhOb3g7rTNdqW8Q28ik7qwenK gK5KmSek7+LZTsx5UD3N4WxdRkUKB30ZIvPt+cH1HMntvulQKJ39Giw9XjXHv8Hc VIsrh/S+2fbfG+4F0aqYmR5WuEXK30mG76DU3DW2o3v8sZ+pvuJ3C37mc0biWGy7 fS722Uh3s6tucs4ToQtwwYkhS93NIUm8uLZJnv3FAUW5EOY7THzf0pplv/ZZEQ62 Sg1bZ4mA7/Tdt25MKM2K04h2ERLTsAiB7Qneh2Ch4yVt3cwnGbZUFCAbXMSq01xE TP6j0zfLAtEx3b6Av22WLqnq5NdSDUYbvVzTQPH/TUERf4ztLRadBjHPEN0gM2vL zQi7BGiJix2K/fjWLicGkZKTPCWvSnknkwPgQ1JzxZwEQmCUA+hRANaZljp7KVwP mObnaRL5QQ/S2NhCRHFdvyLqXMgmbSsMe+FMmN2P8/mADwSdeK8= =4xik -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wildcard certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 4/17/19 10:22, TurboChargedDad . wrote: > I would have the opposite feeling. I would not want a java process > parked out in the internet. Not saying you're wrong just my > personal feeling. It would be interesting to compare the number of remotely-exploitable vulnerabilities there have been in e.g. httpd versus e.g. Tomcat in a given period of time. My guess is that the Java-based servers have had a better track record. The difference is that typically if you own a web server, you just own the web server. But if you own an application server, you typically get access to lots of great stuff like the application's database. > Maybe things have shifted in a different direction over the year. Any particular year? > I do agree that something like that would be helpful to other > tomcat admins. Would you consider putting it into github ? certbot does almost everything you need. There is also this: https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encrypt %20Apache%20Tomcat.pdf So unless John has done something truly amazing, maybe adding more tools to what MUST be a secure toolchain isn't a great move. - -chris > On Wed, Apr 17, 2019 at 9:18 AM John Dale > wrote: > >> I have a really nice process that works great with certbot. >> Single command to renew all of my certs and I'm finished. >> >> I get some piece of mind having a Java process guarding the >> front door. Seems to be more impervious to overflows. What am I >> missing? >> >> I think what I have might be easily developed into something to >> help other Tomcat users. >> >> On 4/17/19, TurboChargedDad . wrote: >>> We terminated SSL above the tomcat layer using NGINX or Apache >>> to avoid the complexities that come with managing a JKS. I >>> want to hear all I can on this subject. >>> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly3WFMACgkQHPApP6U8 pFjFUA//Q5HiqvarK/NO/o2tjtVUVs75RJaTEao7T1eUCwMIf/F9nkpZpNG8TxK7 slT0zu3GMaB5+Z5PK753M3+vZ9nytbat4ODbUNpUMrqeT1/U0eaF1LdbY0jeUmKH hmzQFTtLEtJ9mMYn+KJ3sA8D3sIECWwFuKD+BdYmOkzAZn37HlzyI+1CMr4mEA6C LnhlD/hEeG4HiO5FtE4BxRKZ0vcLhBp10/m27E6j6KDiiwT7+tlNfwD53S5P94vv f/FbwSP8GJfkFu13ot+ce1IVerMNpMpc6nay1efJmYtT4oHyNP0YUVMZyN8YyCTO 5yiLYOj8yXLxLatdKBWJ+1fsqd5DXuOEv0KmaIaqi3pLHg5oJQp5CtsLKTSFVTmV FBoWew1JFhh5DBI27uJntGzlwIGjKAq7Cq0qitL2gVCiDr6HFaI/gkvVriDjoZL/ L3E5JDSpYL/iSzBeBd5qKbGVz7+/bdsHoxdHGRFrvcNYyPZIT871bVoNjvyaSFsM KZGYcgZgruzN6hT3+jmJpHHoINb+XQeViM140HvYJP1zrcyCZ9ejqpw1BSB+WbT0 OutjYugoJwORD2SWFTXAc5g6flP5I6JYogexzlj0UPx6v0969I6OBPkLRyMzyKnr RTSLV2mYJifNFjLvJ98blhhRmZG3BgAJR4ussur1NTZzs6I03Bc= =4l6s -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wildcard certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 4/17/19 09:44, TurboChargedDad . wrote: > We terminated SSL above the tomcat layer using NGINX or Apache to > avoid the complexities that come with managing a JKS. I want to > hear all I can on this subject. It's not necessary to handle JKS files to use Tomcat for TLS termination . You can use PEM-encoded DER files (same as httpd, nginx, etc.) if you use any connector along with the OpenSSL engine. You can also use PKCS12 files (similar to JKS files, but much more standard) which openssl knows how to manipulate (as does Java's "keytool") with any JSSE-based crypto engine. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly3VzcACgkQHPApP6U8 pFhOwxAAtd5d0UDSp1SEjZWKu+AX970vUTZIc+UxeWAWcwG20MjBeHa4PBzrJFIK QVduzNGBJvi2oez9QV3LCnLo2jkIgpZG6EC/+TBQSSfAn8iGrL7lc59vWXg551PC 8+llFd9q3M13dqyx824YijMPptwFxH36z0K2pr34ytZOP1g/QDUA07dW5rW2rJKF tdOkHIE/QvEE+iSQnrYQbNNknBk/grzbxDwg7lZupSi1UBY080Hc8aPzWknBADKh zPKt6942WMvrIDmK8yCQSgkqjG8QWrZfR5QNkvnkRN4rridK4TevYm6Da/QI46w3 NPSozJeNKGeaUylabH4jTcVBE3eynOcP0oyBJ7/MmMzu1a9jU9ar7mZmTlZEPaEV f3jxmfQ5m4AmbypNfwLzudo0ekVQceD33Ba04/VO9wGESMNSQTF6XIz69BSHvj1s KsIIFcgdWuVH5ae5UxgirWghecz2xZAu7BHXYtkPdLcmF/RgTR1lQQ34JDlB9VPM NdtZuVUWasnlWVGF4YDV6RzQwdhzGk4FUd38ULRzsc+ycyA0LtbdQfyear/N/dxl c4s+nPiub1lnggMbd990uPMhoy8AaEGq4GG6NyKXvBz1sUw72n27QO6tCEIinQSe E8OOofUgHAcLwuEQxLO/bvVnD77Vx95lxnIoludx51BvEM1ZbbU= =M18j -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wildcard certificates
On Wed, Apr 17, 2019 at 9:20 AM Sean Dawson wrote: > > Hello, I have a widlcard certificate from GoDaddy. Can I use this with > Tomcat? (8.5) > > I have the files crt (primary certificate?), p7b (intermediate?), pfx > (private key?), and a .key file. I did not generate a certificate request > prior to this. > > Google is telling me that either I need to generate a certificate request > first, or it's telling everything I need to know about wildcard > certificates except how to use the above files. > > This is for Tomcat 8.5 with Java 8 on CentOS 7, and Windows Server 2016. > > Thank you. > > Ok just for others' benefit if they want to go this way, I was able to get it working by concatenating the .key and the .crt file into one .pem. Then do this: openssl pkcs12 -export -in combined.pem -out cert.p12 And then this: keytool -importkeystore -srckeystore cert.p12 -srcstoretype pkcs12 -destkeystore cert.jks (from this page: https://stackoverflow.com/questions/22296312/convert-certificate-from-pem-into-jks ) Sorry for the earlier top posting.
Re: Wildcard certificates
My understanding is that the folks at SUN really put their backs into it from the beginning: https://stackoverflow.com/questions/479701/does-java-have-buffer-overflows Since hot spot compilers have matured, Java is virtually as fast as C/++ (the Java is slow argument falls in my deaf ears, even if it is amazingly repeated still today by members of other programming religions). Other proxies/balancers also do threat mitigation (DDOS, flooding, etc). I have written some of my own code to deal with this .. because of the way I handle data and MVC, I have a central place to park all of the heuristics. I bet these heuristics could become robust and maintainable over time. I would be happy to share (would need a little time to isolate and deliver). I have always wondered how difficult it is to have Apache/Tomcat evaluate new projects. Part of this certbot solution requires providing some automated validation for the certbot CSA agent. This code can stand alone, but I have it integrated with some other tools that have also proven helpful. I wonder if I might attract a sponsorship from someone within ASF for my project? I call it DB2DOM.COM - it's a "pseudosingularity" because it is used to extend and maintain itself. Any ideas I'd love to hear them. Have a good one, John On 4/17/19, TurboChargedDad . wrote: > I would have the opposite feeling. I would not want a java process > parked out in the internet. Not saying you're wrong just my personal > feeling. Maybe things have shifted in a different direction over the > year. I do agree that something like that would be helpful to other tomcat > admins. Would you consider putting it into github ? > > Thanks, > J > > On Wed, Apr 17, 2019 at 9:18 AM John Dale wrote: > >> I have a really nice process that works great with certbot. Single >> command to renew all of my certs and I'm finished. >> >> I get some piece of mind having a Java process guarding the front >> door. Seems to be more impervious to overflows. What am I missing? >> >> I think what I have might be easily developed into something to help >> other Tomcat users. >> >> On 4/17/19, TurboChargedDad . wrote: >> > We terminated SSL above the tomcat layer using NGINX or Apache to >> > avoid >> > the complexities that come with managing a JKS. I want to hear all I >> > can >> > on this subject. >> > >> >> - >> 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: Wildcard certificates
I would have the opposite feeling. I would not want a java process parked out in the internet. Not saying you're wrong just my personal feeling. Maybe things have shifted in a different direction over the year. I do agree that something like that would be helpful to other tomcat admins. Would you consider putting it into github ? Thanks, J On Wed, Apr 17, 2019 at 9:18 AM John Dale wrote: > I have a really nice process that works great with certbot. Single > command to renew all of my certs and I'm finished. > > I get some piece of mind having a Java process guarding the front > door. Seems to be more impervious to overflows. What am I missing? > > I think what I have might be easily developed into something to help > other Tomcat users. > > On 4/17/19, TurboChargedDad . wrote: > > We terminated SSL above the tomcat layer using NGINX or Apache to avoid > > the complexities that come with managing a JKS. I want to hear all I can > > on this subject. > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Wildcard certificates
I have a really nice process that works great with certbot. Single command to renew all of my certs and I'm finished. I get some piece of mind having a Java process guarding the front door. Seems to be more impervious to overflows. What am I missing? I think what I have might be easily developed into something to help other Tomcat users. On 4/17/19, TurboChargedDad . wrote: > We terminated SSL above the tomcat layer using NGINX or Apache to avoid > the complexities that come with managing a JKS. I want to hear all I can > on this subject. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wildcard certificates
Multi-tenant or single tenant system? On Wed, Apr 17, 2019 at 8:54 AM Sean Dawson wrote: > Thanks for the replies - I'm willing to use NGINX to handle this for us - > can you point me to a good page on that? > > > On Wed, Apr 17, 2019 at 9:46 AM John Larsen > wrote: > > > We do the same - via mod_jk we utilize apache httpd to handle the SSL. > > Keeps things simple and works well. > > John Larsen > > > > On Wed, Apr 17, 2019 at 7:44 AM TurboChargedDad . > > > wrote: > > > > > We terminated SSL above the tomcat layer using NGINX or Apache to > avoid > > > the complexities that come with managing a JKS. I want to hear all I > can > > > on this subject. > > > > > >
Re: Wildcard certificates
Thanks for the replies - I'm willing to use NGINX to handle this for us - can you point me to a good page on that? On Wed, Apr 17, 2019 at 9:46 AM John Larsen wrote: > We do the same - via mod_jk we utilize apache httpd to handle the SSL. > Keeps things simple and works well. > John Larsen > > On Wed, Apr 17, 2019 at 7:44 AM TurboChargedDad . > wrote: > > > We terminated SSL above the tomcat layer using NGINX or Apache to avoid > > the complexities that come with managing a JKS. I want to hear all I can > > on this subject. > > >
Re: Wildcard certificates
We do the same - via mod_jk we utilize apache httpd to handle the SSL. Keeps things simple and works well. John Larsen On Wed, Apr 17, 2019 at 7:44 AM TurboChargedDad . wrote: > We terminated SSL above the tomcat layer using NGINX or Apache to avoid > the complexities that come with managing a JKS. I want to hear all I can > on this subject. >
Re: Wildcard certificates
We terminated SSL above the tomcat layer using NGINX or Apache to avoid the complexities that come with managing a JKS. I want to hear all I can on this subject.
Wildcard certificates
Hello, I have a widlcard certificate from GoDaddy. Can I use this with Tomcat? (8.5) I have the files crt (primary certificate?), p7b (intermediate?), pfx (private key?), and a .key file. I did not generate a certificate request prior to this. Google is telling me that either I need to generate a certificate request first, or it's telling everything I need to know about wildcard certificates except how to use the above files. This is for Tomcat 8.5 with Java 8 on CentOS 7, and Windows Server 2016. Thank you.
Re: Upgrade from Tomcat 7 to Tomcat 9.0.17
Hello Akram,
If you can not put the jars inside each webapp perhaps you could define a
shared.loader in your catalina.properties [1]. It works for us.
Hope it helps,
Luis
[1]
https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html#Advanced_configuration
El mar., 16 abr. 2019 a las 23:21, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Akram,
>
> On 4/16/19 16:21, Akram Hussain wrote:
> > Hi Christopher,
> >
> > I have almost 27-30 apps in my tomcat.
> >
> > Do I need to declare in every applications's META-INF\context.xml.
>
> Yes. If every application needs those libraries, then you'll need to
> configure them. Just like you had to configure your custom class
> loader for each application in the past.
>
> Why not simply put the JAR files into the applications as usual? Then
> each web application is self-contained and you don't have to go
> through all these back-flips.
>
> > And also I have a listener class which is in tomcat\lib folder,
> > which also access these shared classes using CustomSharedLibrary.
>
> Then you can put all the libraries into Tomcat's lib/ directory and
> you don't have to do any of this.
>
> > How can I access those shared libraries in listener which is in
> > tomcat\lib folder?
>
> What does your Listener do? You might not even need it...
>
> - -chris
>
> > On Wed, Apr 17, 2019 at 1:02 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Akram,
> >
> > On 4/16/19 12:41, Akram Hussain wrote:
> I have gone through it, But it was not clear to me.
>
> If an example is provided, how to pass resources to
> SharedClassLoader, it could be helpful.
> >
> > If you configure something like this in your META-INF/context.xml:
> >
> > > base="/path/to/your/shared/libraries"
> > className="org.apache.catalina.webresources.DirResourceSet" />
> >
> >
> > That should allow your application to load JAR files from your
> > /path/to/your/shared/libraries directory.
> >
> > You should completely remove your custom class loader. Completely.
> >
> > -chris
> >
> On Tue, Apr 16, 2019 at 7:57 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Akram,
>
> On 4/16/19 06:29, Akram Hussain wrote:
> >>> I have Custom SharedClassLoader in Tomcat 7 to load
> >>> shared library jars, which is used by different
> >>> applications in that tomcat. We migrated to Tomcat 9,
> >>> now it is not working. How to achieve the same
> >>> functionality in tomcat 9.
>
> Have a look at the which should be able to do
> what you need without any custom code:
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>
> >>>
>
> In Tomcat 9 it expects resources to be passed. I don't find
> >>> any sample Code on how to populate resources.
> >>>
> >>> I tried like below
> >>>
> >>> public CustomSharedClassLoader(ClassLoader parent)
> >>> throws Exception { super(parent); //The below three
> >>> lines are added by me to work for Tomcat 9.
> >>> StandardRoot standardRoot = new StandardRoot();
> >>> standardRoot.addPreResources(new DirResourceSet());
> >>> setResources(standardRoot);// End for tomcat 9
> >>> changes.
> >>>
> >>> for (URL urlForJars : getClassPath(SHARED_LIB)) {
> >>> addURL(urlForJars); } start(); }
> >>>
> >>> It didn't work.
> >>>
> >>> public class CustomSharedClassLoader extends
> >>> WebappClassLoader{//Which takes shared folder libarary,
> >>> it returns those classes.}
>
> You should be able to ditch your custom ClassLoader
> entirely.
>
> -chris
> >
> > --
> - ---
> >
> >
> >
> >
> 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
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly2RzgACgkQHPApP6U8
> pFilIA/+NvG9+sG1tPbWyAXvy9bwGnRATgTZqxGGWvGZ2XL2Knkt+lPaoh7Vtum9
> jYm4ZUIWNrkg4APxCwHXnfNlkLEF36igANlytDlBBUoVKBqEgngWUqR2w19yeRma
> 8GS7YbDS6bUJ/KQTBEkeTeyf7EdLHVfJwrnKZ6qxV2QmC+IBwCr7I2vlWwx59qac
> CqCL97FzRjtwDa6sHsC5PYsdu0fy8z4NzI4Ro4bcKNjDnvsQ0LSaKR0WM6OlaHAW
> wFayoV/oUK8uRbDrS3q4pOtAnLxwF+CVrk0x7clpyPnqlSO0TIebZ+ejOEe4lsHK
> gC33pK+vpKtl3d68WNf4aZfjXdrqsnF0IvnPPayAThVysHHOfJqGyYL2wdtmFru9
> vOKKIPqM4TT6V0BWZiX4lrE/kbF8c4KhpdtdIkFyf8KqWtezYBZIjIlEEaoiqlSO
> KWdnrxRQ3Y2gJMUBAUDK0CiEl8Rw/L030CUmeLabNvN8MORpva2GOIGUk2wUVRwB
>
