I have been running a Glassfish4 server with an SSL Certificate for my Websocket based app for a number of months now. I recently switched to Payara5. When I set up the Payara server, everything worked great. Now, the certificate has expired, and after renewing it (same process I've always done), the Payara server still thinks it's using the old certificate.
The process I've been going through since the beginning is:
cert-bot renews the certificate automatically.
replace the old certificate with the new certificate in the keystore I'm using
restart the server
This works, and has always worked, for my Glassfish server. But not the Payara server. I've had to revert to Glassfish while I try and figure this out. I checked in the keystore in Payara for the alias, and it shows the new certificate's expire date. So, as far as I can tell, it should be fine.
The commands I've used to renew the certificate are as follows:
openssl pkcs12 -export -in $LETS_ENCRYPT/live/www.mywebsite.com/fullchain.pem -inkey $LETS_ENCRYPT/live/www.mywebsite.com/privkey.pem -out $LETS_ENCRYPT/live/www.mywebsite.com/pkcs.p12 -name mywebsite.com
keytool -importkeystore -deststorepass *password* -destkeypass *password* -destkeystore $LETS_ENCRYPT/live/www.mywebsite.com/letsencrypt.jks -srckeystore $LETS_ENCRYPT/live/www.mywebsite.com/pkcs.p12 -srcstoretype PKCS12 -srcstorepass *password* -alias mywebsite.com
keytool -importkeystore -srckeystore $LETS_ENCRYPT/live/www.mywebsite.com/letsencrypt.jks -destkeystore $PAYARA_HOME/glassfish/domains/domain1/config/keystore.jks
$PAYARA_HOME/bin/asadmin restart-domain
I checked the keystore afterwords with:
keytool -v -list -keystore $PAYARA_HOME/glassfish/domains/domain1/config/keystore.jks -alias mywebsite.com
and it shows:
Certificate[1]:
Owner: CN=www.mywebsite.com
Issuer: CN=Let's Encrypt Authority X3....
Serial number: ******
Valid from: Wed Apr 03 17:22:48 PDT 2019 until: Tue Jul 02 17:22:48 PDT 2019
The error from the client app shows:
…
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at org.glassfish.grizzly.ssl.SSLUtils.sslEngineWrap(SSLUtils.java:427)
at org.glassfish.grizzly.ssl.SSLConnectionContext.wrap(SSLConnectionContext.java:337)
at org.glassfish.grizzly.ssl.SSLUtils.handshakeWrap(SSLUtils.java:303)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:673)
at org.glassfish.grizzly.ssl.SSLFilter.doHandshakeStep(SSLFilter.java:308)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:598)
at org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:310)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:515)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:966)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:963)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416)
at org.glassfish.grizzly.ssl.SSLUtils.executeDelegatedTask(SSLUtils.java:250)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:684)
... 17 more
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:362)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:270)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1501)
... 25 more
Caused by: java.security.cert.CertPathValidatorException: validity check failed
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:223)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:357)
... 31 more
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Fri May 17 12:21:27 PDT 2019
at sun.security.x509.CertificateValidity.valid(CertificateValidity.java:274)
at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:629)
at sun.security.provider.certpath.BasicChecker.verifyValidity(BasicChecker.java:190)
at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:144)
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
... 36 more
Which would indicate it is using the old certificate, or something along those lines.
I discovered that I have two keystore.jks locations. The one that my Payara server defaults to is located in the
$PAYARA_HOME/glassfish/domains/domain1
not
$PAYARA_HOME/glassfish/domains/domain1/config
The JVM Option for the keystore location is set to :
-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks,
so I thought I was altering the correct keystore. But, I suppose Payara doesn't use this value, or I have it set wrong. Either way, I just changed my script file to use the domain1/keystore.jks instead of domain1/config/keystore.jks.
Perhaps I goofed my setup and this all could have been avoided. But I figure I should leave this here anyway, in case someone else has a similar issue.
Related
I am getting the following error while trying to connect to LDAP Server.
Is there a way to Ignore SSL Security Certificate. I am able to connect to the server outside of JMeter using other tools.
Thread Name: Thread Group 1-1
Sample Start: 2018-09-23 12:16:48 EDT
Load time: 154
Connect Time: 0
Latency: 0
Size in bytes: 555
Sent bytes:0
Headers size in bytes: 0
Body size in bytes: 555
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 800
Response message: javax.naming.CommunicationException: x.x.x.x:1636
[Root exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target]
Response headers:
SampleResult fields:
ContentType: text/xml
DataEncoding: UTF-8
the best (and most common) way to solve this is to trust the LDAPS server, i.e. add the server's certificate to JRE's cacerts file using keytool. There is already an s-o answer on how to do this (here: Is there a java setting for disabling certificate validation?) - the gist is (taken from there)
cd %JRE_HOME%
keytool -alias REPLACE_TO_ANY_UNIQ_NAME -import -keystore ..\lib\security\cacerts -file your.crt
When you don't have the public key (certificate file) yet, you can e.g. get it by connecting to the LDAPS server with Apache Directory Studio (https://directory.apache.org/studio/) which stores all public keys of LDAPS servers you trust. The exact routine was described on the mailing list already (here: http://mail-archives.apache.org/mod_mbox/directory-users/201004.mbox/%3C4BBF6471.6040900#apache.org%3E), so I'm just giving the gist (again largely taken from there)
find ~/.ApacheDirectoryStudio -name \*.jks # gives you the keystores managed by DirectoryStudio
keytool -list -keystore path/to/permanent.jks
keytool -exportcert -alias <aliasname> -keystore path/to/permanent.jks -file your.crt
Most probably it indicates the issue with your LDAP server SSL setup, i.e. one of certificates in chain cannot be checked against authority. I would recommend double-checking the certificate chain using i.e.
OpenSSL tool like: openssl s_client -showcerts -connect yourhost:yourport
SSLPoke tool like: java -Djavax.net.debug=ssl SSLPoke yourhost yourport
You have 2 ways:
Add the certificate into the JVM truststore like:
keytool -import -file your_ldap_certificate -alias certificate -keystore trustStore.keystore
Create a custom class which will be trusting all the certificates and set java.naming.ldap.factory.socket system property to point to that class (the class must be in the JMeter Classpath)
Just in case if you need more information on LDAP servers performance testing with JMeter check out How to Load Test LDAP with Apache JMeter™ article.
I have setup solr on local system. It works fine without ssl however for SSL solr gives exception:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:214)
at org.eclipse.jetty.start.Main.start(Main.java:457)
at org.eclipse.jetty.start.Main.main(Main.java:75)
Caused by: java.io.IOException: Invalid keystore format
I have generated p12 and jks using commands:
“C:\Program Files\Java\jdk-10.0.1\bin\keytool.exe” -genkeypair -alias solr-ssl -keyalg RSA -keysize 2048 -keypass secret -storepass secret -validity 9999 -keystore solr-ssl.keystore.jks -ext SAN=DNS:localhost,IP:127.0.0.1 -dname “CN=localhost, OU=Organizational Unit, O=Organization, L=Location, ST=State, C=Country”
and
“C:\Program Files\Java\jdk-10.0.1\bin\keytool.exe” -importkeystore -srckeystore solr-ssl.keystore.jks -destkeystore solr-ssl.keystore.p12 -srcstoretype jks -deststoretype pkcs12
Kept secret as password for all phrases. Copied the jks and p12 file to solr-6.6.2/server/etc folder. Updated the solr.in.cmd file and uncommented these lines:
SET SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
SET SOLR_SSL_KEY_STORE_PASSWORD=secret
SET SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
SET SOLR_SSL_TRUST_STORE_PASSWORD=secret
SET SOLR_SSL_NEED_CLIENT_AUTH=false
SET SOLR_SSL_WANT_CLIENT_AUTH=false
SET SOLR_SSL_KEY_STORE_TYPE=JKS
SET SOLR_SSL_TRUST_STORE_TYPE=JKS
When I try to run with: solr -p 8984 it gives the above said exception.
Can you please help me out with the setup. Been googling but can't seem to find the resolution.
Ok I have resolved the issue. Seems like my java version was
"1.8.0 ea"
. When I uninstalled and reinstalled the new version
"1.8.0_171"
, solr started in https.
I also tried java version 10 and it had the same issue with solr 6.6.2
Although my site's certificate is fine, ("openssl verify mysite.com.cer" resulted in OK), and my site is ssl-certified including green lock in the url-bar, my site is generating a fatal alert: bad_certificate whenever a subscriber in my WSO2 app executes an api.
[2018-06-08 10:54:47,167] ERROR - SourceHandler I/O error: Received fatal alert: bad_certificate
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1083)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:245)
at org.apache.http.nio.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:378)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:413)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:119)
at org.apache.http.impl.nio.reactor.BaseIOReactor.validate(BaseIOReactor.java:218)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:281)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:586)
at java.lang.Thread.run(Thread.java:748)
I browsed through several stackoverflow-questions about 'bad_certificate' but found no solution.
To import my certificate I followed WSO2's docs:
openssl pkcs12 -export -in SSL_certificate_www_mysite_com.crt -inkey www.mysite.com.key -name "mykeys" -certfile mysite.com.cer -out mykeys.pfx
keytool -importkeystore -srckeystore mykeys.pfx -srcstoretype pkcs12 -destkeystore mykeys.jks -deststoretype JKS
keytool -export -alias "mykeys" -keystore mykeys.jks -file mykeys.pem
copied mykeys.pem and mykeys.jks to /usr/local/opt/wso2am-2.2.0/repository/resources/security/
keytool -import -alias "mykeys" -file mykeys.pem -keystore client-truststore.jks -storepass wso2carbon and answered yes to include the certificate
Then I had to change several configuration files to use mykeys instead of wso2carbon. So I did.
Then I restarted wso2-carbon, logged in and checked that mykeys.JKS showed up in the list of keystores, it does.
My site is correctly ssl-certified, green lock showing in the url-bar. All works fine, upto the point that logged in as Subscriber I try to Execute an API, which results in the response "ERROR - SourceHandler I/O error: Received fatal alert: bad_certificate" and the above-mentioned log coming from sourcehandler
This error is logged in repository/logs/wso2-apigw-errors.log and wso2carbon.log, but only this message, nothing else.
Where to look next to find why my certificate is not getting validated correctly?
the problem is in the self-signed certificate
assume your service published at this endpoint:
https://192.168.99.3:8243/first/1.0.0
then you have to go into a new browser window
https://192.168.99.3:8243/
set browser to always accept the https certificate
after this the call in api console should work
If you have separate Store and gateway instances, open the gateway:9443/carbon in browser and accept the self signed certificate. That should work.
I created a custom SSL certificate through Java keytool command, in order to test the connection from my Codename one app and my HTTPS REST web service.
This is the complete command:
keytool -genkey -alias my_alias -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650
When the app (running on the simulator) tries to interact with the web service, it returns the following exception:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I read here
and I understood for a real mobile device is possible to add the custom certificate.
My question is: using the simulator, how can I do? How can I use my "home-made" certificate?
There is really no reason to do this anymore. You can but if you just don't want to pay for a certificate you can just use "lets encrypt" and it will work: http://letsencrypt.org/
Notice that it requires a recent version of JDK 8 (I think 128 or newer).
SSL will only work with proper domains and not with IP addresses etc.
I have installed Nexus Repository Manager OSS 3.0.2-02 on my CentOS Linux release 7.4.1708.
Also I have CA certificate:
Issued to: \*.mycompany.com
Issued by: Go Daddy Secure Certificate Authority - G2
Valid from 2016-11-12 to 2018-01-11
The RSA private key match with my CA certificate, which was checked with Certificate Key Matcher and reported:
The certificate and private key match!
In Nexus3 directory I made the following changes:
Added to the file org.sonatype.nexus.cfg the lines:
nexus-args=${karaf.etc}/jetty.xml,${karaf.etc}/jetty-http.xml,${karaf.etc}/jetty-requestlog.xml,${karaf.etc}/jetty-https.xml
application-port-ssl=8443
Added to jetty-https.xml file next lines:
KeyStorePath /ssl/test.jks
KeyStorePassword 123456
KeyManagerPassword 123456
TrustStorePath ssl/test.jks
TrustStorePassword 123456
Created SSL directory in $NEXUS_HOME/etc/ and created inside the SSL directory a Java keystore file test.jks with command:
openssl pkcs12 -export -in mycompany.com.pem -inkey key.pem -name xxx.mycompany.com -out test.pks
keytool -importkeystore -deststorepass 123456 -destkeystore test.jks -srckeystore test.pks -srcstoretype PKCS12
keytool -import -alias bundle -trustcacerts -file gd_bundle.crt -keystore test.jks
After Nexus restart I can't not reach it by URL //xxx.mycompany.com:8443. Firefox says:
The page you are trying to view cannot be shown because the
authenticity of the received data could not be verified
Also trying to do: docker login xxx.mycompany.com:8443 and providing default admin:admin:123 credentials cause:
Error response from daemon: Get xxx.mycompany.com:8443/v1/users/:
x509: certificate signed by unknown authority
I also try to chain certificates by various scenarions from Google, including How to add certificate chain to keystore?, but got error on Docker:
Error response from daemon: Get //xxx.mycompany.com:8443/v1/users/: EOF
on Firefox, the same as first time and on Chrome:
//xxx.mycompany.com unexpectedly closed the connection
Question: Where is my mistake, or how to correctly install CA certificate on Nexus3?
I've found the resolution. Just needed to set in jetty-https.xml next lines:
<Set name="NeedClientAuth"><Property name="jetty.ssl.needClientAuth" default="false"/></Set>
<Set name="WantClientAuth"><Property name="jetty.ssl.wantClientAuth" default="false"/></Set>