I'm having a major pain getting my new SSL certificate to work with GlassFish 3.1.2.2. My current SSL certificate is due to expire soon, so I ordered a renewal at GlobalSign.
With my current SSL certificate I get following response (this is done through SoapUI for testing purposes):
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (Oracle GlassFish Server 3.1.2.2 Java/Oracle Corporation/1.7)
Server: Oracle GlassFish Server 3.1.2.2
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Mon, 11 Jan 2016 13:38:32 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>..(xmlresponse)..</xml>
However, with the new SSL certificate active, I get following message:
SoapUI:
Error getting response; javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.
Browser:
This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to again. If this error persists, contact your site administrator.
The only thing I changed in the config of glassfish is the following:
Configurations > server-config > HTTP Service > Http Listeners > http-listener-2 > SSL tab
The Certificate NickName field from my old alias (mydomain) to my new alias (mydomain.net), which matches the alias of my private key in the keystore
The Key Store field value (file name) from the old keystore (server.keystore) to my new keystore (ssl_mydomain_net.jks)
Both new and old keystores are inside the C:\glassfish3\glassfish\domains\mydomain\config folder.
Old SSL settings:
New SSL settings:
I already had contact with GlobalSign support and we verified that the keystore is correctly generated.
When I run keytool -list -keystore ssl_mydomain_net.jks I get following output which should be correct:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries
root, Jan 8, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): <...>
intermediate, Jan 8, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): <...>
<mydomain>.net, Jan 8, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): <...>
As far as I concluded, it has something to do with Glassfish. Does anyone have any idea because I'm out of options here...
Update January 13th, 2016
I upgraded from Glassfish 3.1.2.2 to Payara 4.1 (which is basicly Glassfish 4.1). I created a new fresh domain and noticed that by default the following jks files were in the mydomain/config folder:
cacerts.jks
keystore.jks
I added my own jks (ssl_mydomain_net.jks) to this folder and adjusted the settings for the http-listener-2 as above in the new SSL image. This gave me the same result as mentioned at the start of this post.
What am I missing? Do I have to adjust something to the default jks files? Do I have to create a csr from the keystore.jks instead of my own made keystore?
What do I need?
A GlobalSign SSL Certificate
Windows server with IIS installed
Payara instance
Getting your certificate from GlobalSign
Order or renew your SSL certificate at the GlobalSign website. During the process, choose the option Order with AutoCSR. The password of the new certificate will exist out of a password that you have to give during the creating process added by an extra string created by GlobalSign. Please remember this password as you will need it in the next phases.
Once your order is complete, you should be receive a PFX file. Copy this file to the Windows server where IIS is running.
Setting/Changing the master password for Payara
The password of the certificate which will contain your private and public key will have to match the master password of Payara (This can be freely chosen, this is NOT the password of your certification request at GlobalSign). You can change the master password by running following command:
asadmin change-master-password –savemasterpassword=true mydomain
Installing the certificate
Right click the PFX file and choose Install PFX
At the welcome screen, click Next
At the File to import screen, click Next as the PFX file location should be in there by default.
Enter the password. Remember, this is the password you gave up at the certificate creation extended by the string GlobalSign created.
Select the Mark this key as exportable. option.
Select the Include all extended properties. option.
Click Next
In the Certificate Store window, choose the Place all certificates in the following store option.
Click the Browse button.
Choose the Personal store.
Click OK
Click Next
Click Finish
Export the public and private key
Open the Microsoft Management Console (Start > Run > mmc > OK)
Click File > Add/Remove Snap-ins
Choose Certificates under the Available snap-ins list
Click the Add button
In the next window, choose the My user account option
Click Finish
Click OK
In the management console, expand Certificates - Current User > Personal > Certificates. If all want correct, you should see 3 certificates: GlobalSign Domain Validation CA, GlobalSign Root CA and mydomain.net.
Right click the mydomain.net entry
Choose All Tasks > Export...
In the welcome screen, press Next
Choose Yes, export the private key option
Click Next
In the Export File Format window, Choose Personal Information Exchange - PKCS # 12 (.PFX) and select the Include all certificates in the certification path if possible and Export all extended properties options.
Click Next
In the Password window, enter your Payara master password (this has to match!)
Click Next
Select the location were you want to put the export PFX file (e.g. mydomain.pfx) and click Next.
Click Finish
Getting the alias name
Run the following command to find out the generated alias name:
keytool -list -storetype pkcs12 -keystore mydomain.pfx
You will have to enter your keystore password, which should be the same as your Payara master password (see step 29).
When this command runs succesful, you should see your alias on the first line of the export. This looks like a long string of text (e.g. {fa2ebfd3-z11b-492d-2c73-f5z199732p2k}) followed by the date. Copy this string of text as we will need it later.
Adding the certificate to Payara
These are the two important steps that I was missing. We have to add the certificate to the cacerts.jks and keystore.jks who is located in the payara_install_folder/glassfish/domains/mydomain/config. This can be done by following two commands:
keytool -importkeystore -deststorepass <payara masterpassword> \
-destkeypass <payara masterpassword> -destkeystore cacerts.jks \
-srckeystore mydomain.pfx -srcstoretype PKCS12 \
-srcstorepass <payara masterpassword> \
-alias mydomain_alias_name //in our example this would be {fa2ebfd3-z11b-492d-2c73-f5z199732p2k}
keytool -importkeystore -deststorepass <payara masterpassword> \
-destkeypass <payara masterpassword> -destkeystore keystore.jks \
-srckeystore mydomain.pfx -srcstoretype PKCS12 \
-srcstorepass <payara masterpassword> \
-alias mydomain_alias_name //in our example this would be {fa2ebfd3-z11b-492d-2c73-f5z199732p2k}
Setting http-listener in Payara
Open your Payara admin console (normally this would be http://localhost:4848)
Go to Configurations > server-config > HTTP Service > HTTP Listeners > http-listener-2
Enable Security on the General tab
On the SSL tab, Enable SSL3 and TLS
In the Certificate NickName enter mydomain_alias_name (in our case {fa2ebfd3-z11b-492d-2c73-f5z199732p2k})
In the Key Store field, enter keystore.jks
Press the Save button
Restart your domain
Test if it works! :)
Thanks a lot to GlobalSign support and Max Lam who created a guide How To Install Comodo SSL Certificate Chain On Payara / Glassfish 4.x. Combining all this knowledge made me come up with the solution.
There is probably a way to replace the Installing the certificate and Export the public and private key part by running keytool commands. But as I'm not a 100% familiar with certificates, I left those out. If someone can tell me the right commands, let me know and I'll update the answer.
Add your new certificate to the truststore of the JVM that your server is using. If you take a look to your output when list the certificates of your keystore, you could see that your new certificate is not a trustedCertEntry.
Related
I want to convert the following curl into a Postman script:
curl --cacert ca.crt --key client.key --cert client.crt "https://myurl"
All three SSL parts are required, i.e. client cert, client key AND server cert.
In Postman settings - certificates, I can set the CLIENT crt and the client KEY....but how do I set the server cert that is also required otherwise the request will fail.
To resolve this I converted ca.crt, client.key and client.crt into a .pfx file using this command:
openssl pkcs12 -export -out certificate.pfx -inkey client.key -in client.crt -certfile CA.crt
This created a file called certificate.pfx
[You will be prompted whether you want to add a password for the file or not].
Open Postman – click on the settings cog and then choose Settings
Click on Certificates
Click on ‘Add Certificate’ to the right of Client Certificates
In the Host section set the url as required for your API
In the PFX file section click on Select File and browse to certificate.pfx
If you created a password for certificate.pfx - enter that in the Passphrase section
Click on ‘Add’
Close Settings
You should now be able to send the request to the API and get a successful response
I am trying to explore AD integration and was able to succesfully complete the setup as described in AWS blog post, and verified that SSL connection is working fine from "Management box".
Based on my understanding, ldp.exe from Management box is working fine because management box is joined to this AD and certificates are propagated properly.
I have use case where another linux box (which can't be joined to AD) but should use LDAPS over SSL to do some user search. For this to work, I need to export SSL and install it on Linux box. I couldn't quite figure out how to find and export certificates in this example? Are those certificates are available on RootCA (or) SubordinateCA and how to export them? appreciate any help.
I'm assuming you generated the SSL cert in AWS via Amazon Certificate Services (ACS). Although ACS won't allow you to export the private key from ACS, you shouldn't need it. All you need to do is import the public certificate into the certificate trust store that your Linux box is using when it connects to the AD server. I can't tell you how to do that (not sure what the application is), but you should be able to extract the public cert using openssl. You'll point openssl to the ad server, and have it output the public cert.
I'm pretty sure this is the openssl command line that would do that:
openssl s_client -showcerts -connect activedirectory.yourdomain.com:636
You can download the certificate from the ldaps end point and install it as follows.
Install openldap client
sudo yum install -y openldap-clients
• Download and Add Server Certificate to the openldap cert path
openssl s_client -connect <LDAPSURL>:636 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > server.crt
• Configure LDAP Details
Vi /etc/openldap/ldap.conf
BASE dc=corp,dc=example,dc=com
URI ldaps://corp.example.com
TLS_CACERT /etc/openldap/certs/server.crt
I think this is more of a server setup issue?
As the subject says, when I "embed" images to a cfmail, using cfmailparam, if the image is called over https, the email fails. The error I get in mail.log is
javax.mail.MessagingException: IOException while sending message;
nested exception is: java.net.SocketException: Connection reset
Any ideas?
Thx!
Check the {cf_root}/logs/exception.log to see if there is anything more informative.
Sounds like CF isn't liking the SSL certificate. I know some CF versions and using CFHTTP, etc. don't like wildcard or SAN certificates and you have to import those to the keystore.
You have to grab the certificate then use the keytool to import it. This will require a CF restart after.
keytool -import -trustcacerts -keystore ./cacerts -alias myCert -file myCert.cer
Adobe has a write up on how-to: How to import certificates to ColdFusion's truststore
The problem could be because your Java version which is running ColdFusion is not supporting new TLS versions. You can solve this by upgrading Java to 1.8 or later or you can add the following to the JVM config in the ColdFusion Administrator.
-Dhttps.protocols=TLSv1.1,TLSv1.2
Scenario
I have AWS setup for a unifi controller, I've been to access it with https://myserverip:8443, I bypass "This connection is note sucured" and use the controller normally
Now, I need to install and SSL certificate to get the hotspot payment system going.
I have a FQDN with GoDaddy so I created a subdomain unifi.mydomain.com, that points to the elastic IP, I log on with https://unifi.mydomain.com:8443
I bought the SSL certificate from GoDaddy, added the subdomain to that certificate.
I log on my AWS with SSH, generate my csr with the following command
cd /usr/lib/unifi
sudo java -jar lib/ace.jar new_cert unifi.mydomain.dom “My Company Name” City State CC*
Then I do
cd var/lib/unifi
more unifi_certificate.csr.pem
Once I get that I copy and paste it on GoDaddy, download the cert files, go back to AWS copy the files with filezilla to /usr/lib/unifi
Then I run the following command
sudo java -jar lib/ace.jar import_cert unifi_mydomain_com.crt bundlecert.crt
They import correctly, restart unifi service and reboot EC2
When I got to any of the above address I get the following
This site can’t provide a secure connection ERR_SSL_PROTOCOL_ERROR
I've tried different browsers, incognito mode, vpn, etc, I believe it's just a matter of SSL or my server
Check your system.properties which sits in /var/lib/unifi/ open the file with vim or your text editor of choice.
Have a look at your HTTPS options, the important ones are the ciphers and protocols.
The Protocols you need are TLSv1 and potentially SSLv2Hello there should be no other SSL protocols in there.
The Ciphers you ideally want are TLS, so for example TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA
If you are having issues throw them all in, CAUTION! only use this in a demo /test environment.
unifi.https.ciphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA
Remember once you have edited the system.properties you need to restart the controller.
sudo service unifi restart
Lots of help on the Unifi page
UniFi - SSL Certificate Error
UniFi - Explaining the config.properties File
UniFi - system.properties File Explanation
I'm installed WSO2 DAS Server on my LAN network, but I can't create new Dashboard because this error:
javax.net.ssl.SSLException: hostname in certificate didn't match:
<192.168.3.27> != localhost
in log file here.
Please help and thanks
It happens due to certificate is for localhost not for the domain that we run. For that we need to generate new certificate with specific domain and configuration changes with correct .jks file and correct password.
It will resolve the certificate didn't match. We need to replace all the localhost in the portal folder. If I have worked like these and fixed with gaudiness. For more refernce please visit
http://www.vitharana.org/2012/12/how-to-add-new-keystore-to-carbon-4_3.html
Above error log happens due to certificate is for localhost not for the host (192.168.3.27). You can fix this by importing KeyStore file to the trustore by using following commands in the terminal.
keytool -export -alias <HostName> -file mycert.crt -keystore myjks.jks -storepass <pwd>
keytool -import -alias <HostName> -file /usr/local/app/wso2/wso2das-3.0.0/repository/resources/security/mycert.crt -keystore cacerts -storepass changeit
Please refer following articles for more details [1]. On the other hand for a quick test you can access dashboard portal in http by using following URL
http://localhost:9763/portal/
[1] https://medium.com/#dunithd/wso2-das-how-to-fix-javax-net-ssl-sslexception-160c13bc8fe7#.npua5d4nf