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.
Related
I am trying to setup 2 way ssl authentication. My requirement is broker should authenticate only specific clients.
My organization has a CA which issue all certificates in pkcs12 format. steps i followed are as follows.
get a certificate for the broker and configured it in the broker keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
ssl.client.auth=required
get a certificate for the client and configured it in the client keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
extracted the public certificate from the client certificate using keytool command
keytool -export -file cert -keystore certificate.p12 -alias "12345" -storetype pkcs12 -storepass xxxxx
imported the certificate into broker truststore. broker truststore contains only the client 12345 certificate.
keytool -keystore truststore.p12 -import -file cert -alias 12345 -storetype pkcs12 -storepass xxxxx -noprompt
configured the truststore in the broker.
ssl.truststore.location=/home/kafka/truststore.p12
ssl.truststore.password=xxxxx
configured the truststore in client. client truststore contains CA certificates.
ssl.truststore.location=/etc/pki/java/cacerts
ssl.truststore.password=xxxxx
When i run the broker and client i expect the broker to authenticate the client and establish ssl connection. but instead following error is thrown.
[2021-06-03 23:32:06,864] ERROR [AdminClient clientId=adminclient-1] Connection to node -1 (abc.com/10.129.140.212:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2021-06-03 23:32:06,866] WARN [AdminClient clientId=adminclient-1] Metadata update failed due to authentication error (org.apache.kafka.clients.admin.internals.AdminMetadataManager)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLProtocolException: Unexpected handshake message: server_hello
I tried various things but nothing seems to work. when i replace the broker truststore with /etc/pki/java/cacerts truststore file which contains only the CA certificate
then it works fine. but it will authenticate any client which has certificate issued by the CA.
what could be the issue ?
The default format is jks,
use keytool to create a Java KeyStore (JKS) with the certificate and key for use by Kafka. You'll be prompted to create a new password for the resulting file as well as enter the password for the PKCS12 file from the previous step. Hang onto the new JKS password for use in configuration below.
$ keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12 -alias myserver.internal.net
Note: It's safe to ignore the following warning from keytool.
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12"
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>
For couple of days I'm trying to set up my development environment for certificate-based client authentication and it just don't want to work. I'm using the Glassfish 4 documentation (security guide) and creating according to it self signed client certificate for test purposes but I'm not sure what I'm missing, since there is not complete description of the whole process. When I enable Client Authentication for my Http-Listener and don't get any error message in the server log, but when I try to connect from a browser I just cannot establish a connection with the server. Without this option my web application is working just fine. In chrome I see the following message:
This site can’t be reached
127.0.0.1 refused to connect.
ERR_CONNECTION_REFUSED
And in firefox:
The connection to 192.168.1.9:8181 was interrupted while the page was loading.
So for me it seems that something (unfortunately I cannot understand what exactly) is happening, but a connection cannot be established.
Since the setup is pretty complex I'm looking for a tutorial or how-to page which has step by step instruction, but any help and advise will be higly appreciated.
Ok, I finally got it how it works :) I found very good step by step instructions in the book Java EE 7 with GlassFish 4 Application Server, Chapter 9, The cerrtificate realm (p. 247)
One have to basicly do the following 3 Steps:
Create Client Certificate
1.1 Generate a self-signed certificate:
keytool -genkey -v -alias myalias -keyalg RSA -storetype PKCS12 -keystore clientCert_1.p12 -storepass wonttellyou -keypass wonttellyou
1.2 Import it in a browser
NB!: When the certificate is not imported the browser doesn't ask for it, but instead returns a connection error message, which for me is pretty misleading.
Export the certificate from step 1. into a format that Glassfish can understand
keytool -export -alias myalias -keystore clientCert_1.p12 -storetype PKCS12 -storepass wonttellyou -rfc -file clientCert_1.cer
RESULT => Certificate stored in file clientCert_1.cer
Since we issued a self-signed certificate, in order for GlassFish to accept our certificate, we need to import it into the cacerts keystore.
keytool -import -v -trustcacerts -alias myalias -file clientCert_1.cer -keystore ../cacerts.jks -keypass changeit -storepass changeit
Note
The part: -import -v -trustcacerts is not in the book, but without
it the keytool may crash throwing an exception.
changeit is the default glassfish password
Finally one needs to setup the application server for certificate based client authentication, which has two parts. The first one is adding the a login configuration to web.xml:
...
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>certificate</realm-name>
</login-config>
...
And the second one is configuring the role mapping in glassfish-web.xml, so that your application has a corresponding role for that login. It looks like this:
...
<security-role-mapping>
<role-name>YOUR_ROLE</role-name>
<group-name>YOUR_GROUP</group-name>
<principal-name>CN=Test User, OU=n/a, O=Test User, L=Cologne, ST=NRW, C=DE</principal-name>
</security-role-mapping>
...
For more detailed information, about key generation and setting up your glassfish consult the book.
And finally one more thing which was confusing for me. Over the admin interface one can find the SSL configuration tab of an existing http-listener. You don't have to enable the Client Authentication option!
I have been attempting to help one of our sites with an error message they are getting while using an application that uses Glassfish. When signing into the application, the following errors are thrown:
CommunicationException: An error occurred while making the HTTP request to . This could be due to the fact that the server certificate is notconfigured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.
In Server.log, the following is displayed:
0400|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=287;_ThreadName=Thread-1;|Failed to load keystore type JKS with path C:\glassfishv3\glassfish\domains\domain1/config/keystore.jks due to Keystore was tampered with, or password was incorrect
java.io.IOException: Keystore was tampered with, or password was incorrect
The site is only experiencing this problem when they change the glassfish master password. When the master password is left as its default setting, everything works correctly. The default master password is "changeit".
Additionally, the site generates and imports a certificate for use with glassfish. The following are the steps that are performed, in order, for generating a certificate and changing the password:
Stopped Glassfish service.
Opened MMC.MSC: Action --> All Tasks --> Request New Certificate
From the Certificate Enrollment wizard, chose a Computer type certificate. Click Properties Button and configure certificate. It gets a friendly name of "s1as" and an exportable private key of key size 2048. Private key is exported as a pfx file and certificate is exported as a cer file. The files are saved in the glassfish config folder. Details about this process available if needed.
DOS prompt opened and this command is run inside the glassfish config folder:
keytool -delete -alias s1as -keystore keystore.jks -storepass changeit
Following command is run:
keytool -import -v -trustcacerts -alias -file root.cer -keystore cacerts.jks -storepass changeit
Answered "Y" to trust the certificate.
Ran the following command to replace the original self-signed certificate with the pfx one.
keytool -importkeystore -srckeystore .pfx -srcstoretype pkcs12 -destkeystore keystore.jks -deststoretype JKS
Entered password, and a success message appears afterwards that 1 entry was succesfully imported.
Ran this command:
keytool -list -keystore keystore.jks -rfc
A lot of output is produced, including a long Alias name. Thsi long alias is used in the next command.
Ran the following command:
keytool -changealias -alias "" -destalias "s1as" -keypass changeit -keystore keystore.jks -storepass changeit
Ran the following command in asadmin:
change-master-password --savemasterpassword=true
Entered Current password of "changeit"
Entered new password of 123456
Re-entered 123456.
Success message that master password changed succesfully.
Started glassfish service
In my local testing, this procedure has worked and I am able to use the application with no errors. But on the site I am aiding, when they follow the same process, they receive the errors I listed at the top of this message.
My specific questions:
Could the site's certificate be causing this problem? If so, is there a way I could test that the certificate is the issue?
What other things might potentially be generating the errors? Could the "change-master-password" command not be properly changing the password, or could there be something else that needs to have the password changed as well?
I have found the solution to this, and I am posting it here should someone in the future encounter the same issue that I have. Hopefully this will save someone much frustration some day.
In domain.xml, the following 2 lines needed to be added in the jvm-options area.
<jvm-options>-Djavax.net.ssl.keyStorePassword=[password]</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStorePassword=[password]</jvm-options>
We use ActiveMQ to queue up messages from remote clients.
The clients use the following URL to connect to ActiveMQ on our server;
ssl://www.mydomain.com:61616
This worked fine in the past and was set up by a developer know longer with the company.
Recently we had to update our SSL Cert as the old one had ran out. We did this successfully for our http server but have only now realised that a copy of the original keystore still resided in the ActiveMQ config folders.
We have tried to place the new keystore into the ActiveMQ config folders, overwriting the old keystore. However this does not appear to work and all connections are rejected with the following stack trace;
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source)
at java.security.cert.CertPathBuilder.build(Unknown Source)
What are we doing wrong here?
We've listed the contents of both the old and new keystore using the keytool -list command and they appear to be very similar (apart from the dates of course).
Is there additional updates we need to make to the clients calling the above url to accept our new keystore?
It may be that your truststore is out of synch with your keystore. Here is the general way to set it up from scratch; your config will differ, so adapt as needed:
Generate certs for each of the clients, and register the client certs with the broker truststore.
> keytool -genkey -alias producer -keyalg RSA -keystore myproducer.ks
> keytool -genkey -alias consumer -keyalg RSA -keystore myconsumer.ks
Export both certs
> keytool -export -alias producer -keystore myproducer.ks -file producer_cert
> keytool -export -alias consumer -keystore myconsumer.ks -file consumer_cert
Import the certs into the producer truststore (new file)
> keytool -import -alias producer -keystore mybroker.ts -file producer_cert
> keytool -import -alias consumer -keystore mybroker.ts -file consumer_cert
Copy the broker truststore to whichever location you had the old one in, usually {ACTIVEMQ_HOME}/conf. You can generally see this in your broker config:
<broker ...>
<sslContext>
<sslContext keyStore="file:${activemq.base}/conf/mybroker.ks"
keyStorePassword="test123"
trustStore="file:${activemq.base}/conf/mybroker.ts"
trustStorePassword="test123"/>
</sslContext>
</broker>