I have got a RapidSSL certificat and trying to install it on my Glassfish 4.0.
When I change Certificate NickName for http-listener-2 from s1as to saljex the server stops responding to https-requests.
My procedure:
openssl req -sha256 -new -key domain.key -out domain.csr
Order RapidSSL with domain.csr, copy the received certificate to file cert.txt.
keytool -import -alias saljex -keystore keystore.jks -trustcacerts -file cert.txt
Logging in to glassfish admin and change Certificate NickName for http-listener-2 from s1as to saljex.
Server stops responding to https-requests, and starts responding if I change back to s1as.
Trying to change all references in domain.xlm from s1as to saljex and now also admin-port stops responding.
I cant find any information in he log files.
Any help appreciated...
Customer support mentioned that I forgot to import my private key. I don't know exactly what I did, but the key was the key.
Related
I am developing a REST server that runs with Jersey on Glassfish, and I want to make it run on HTTPS on localhost.
I have found many tutorials for generating a CA cert, others for generating .cer / .crt / .key / .csr / ... files, others for generating a jks keystore.
But they do not answer my (very basic) question: how to generate a self signed certificate and use it in my app that runs on Glassfish, on localhost? From scratch to the integration for a real usage, without any prerequiresite having a crt, a jks or any other file.
(For information I use Linux)
Thanks
EDIT: I have finally created a certificate with the following commands
openssl req -x509 -out localhost.crt -keyout localhost.key \
-newkey rsa:2048 -nodes -sha256 \
-subj '/CN=localhost' -extensions EXT -config <( \
printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
openssl pkcs12 -export -name localhostServerCert -in localhost.crt -inkey localhost.key -out localhostP12Keystore.p12
keytool -importkeystore -destkeystore localhostKeystore.jks -srckeystore localhostP12Keystore.p12 -srcstoretype pkcs12 -alias localhostServerCert
copy localhostKeystore.jks into /glassfish/domains/domain1/config
keytool -importkeystore -srckeystore localhostKeystore.jks -destkeystore keystore.jks
And I have modified http-listener-2 in the admin console with certificate nickname localhostServerCert, but I got an error page on https://localhost:8181 (ERR_CONNECTION_REFUSED)
EDIT 2 : I think there should be a problem with the certificate, since openssl s_client -showcerts -connect localhost:8181 returns no peer certificate available, No client certificate CA names sent
COMMON GOALS
It can be useful to run with SSL locally, and I like to start with real world URLs. This can also help you to think ahead to your production deployment design, which often involves a Private PKI these days, based on a self issued Root CA.
Web and API domains can sometimes be related these days, eg if an API issues secure cookies for the web origin. So for localhost development I first define URLs such as these:
https://api.mycompany.com
https://web.mycompany.com
DEVELOPER SETUP
Then add entries such as this to my hosts file:
127.0.0.1 localhost web.mycompany.com api.mycompany.com
:1 localhost
Then, in terms of certificates, I produce these deployable files:
Certificate
Filename
Usage
Root CA
mycompany.ca.pem
The root certificate authority that is trusted by the Java runtime
Wildcard Certificate
mycompany.ssl.p12
A password protected PKCS12 file deployed with the API
My Development Certificates Repository has an example of how to issue the certs using openssl, including a bash script you can use for your own domains. Essentially this is a Private PKI for a development computer.
CONFIGURING TRUST
You then just need to trust the Root CA in the Java runtime used by Glassfish. Personally I tend to avoid JKS files where possible, since they are specific to Java, whereas PKCS12 files are a more portable concept:
sudo "$JAVA_HOME/bin/keytool" -import -alias mycompanyroot -cacerts -file ~/Desktop/mycompany.ca.pem -storepass changeit -noprompt
FURTHER DEVELOPER SETUP INFO
These resources on a portable way to manage SSL development certs are provided below, which completes the architecture work:
My Developer SSL Blog Post
My Java API uses the above certs and loads the wildcard certificate via this code, where a P12 file is used as a keystore:
System.setProperty(
"server.ssl.key-store",
configuration.getApi().getSslCertificateFileName());
System.setProperty(
"server.ssl.key-store-password",
configuration.getApi().getSslCertificatePassword());
GLASSFISH
If Glassfish based setups mean the API itself does not load the PKCS12 file, then there may be a specific task to import the PKCS12 file. Many systems provide a GUI or API option for loading a PKCS12 file into a keystore. This may result in a command like this being run, which you can do manually if needed:
keytool -importkeystore -srckeystore mycompany.ssl.p12 -srcstoretype pkcs12 -destkeystore keystore.jks -deststoretype jks -v
Has anyone managed to install a CA certificate into an activemq instance? I've been doing google searches and reading the activemq documentation but I haven't found anything on how to use a pre-existing CA certificate in activemq.
I assume I install it into the activemq keystore. Is that correct? I'll be using it with websockets and mqtt on the client end.
Also, just in case my assumptions are incorrect, here's why I think I need to use my current CA certificate.
1) I have a web application and our users require communication with the server to be secure. All http traffic is secure.
2) All modern web browsers have a same-origin policy for websockets. They also seem to have a no-mixed-content policy. And so because my http traffic is secure I also have to use secure websockets. (I also have to run the activemq server at the same url)
I'd rather not tunnel the websocket traffic over http because then I have to worry about the apache configuration in addition to the activemq configuration - just another place for things to potentially go wrong.
Also, I don't transfer any sensitive information over the websocket so I could potentially leave it unsecured, but first, my users probably wouldn't understand that, but also it looks like browsers have a no-mixed-content policy.
Has anyone gone through what I'm going through? Any tips?
I eventually got this working, but ultimately I decided to tunnel my websockets communication through apache using the ws_tunnel module.
But to answer my question above, basically what you have to do is create a new java keystore based on your webserver keys, and then replace the apachemq java keystore with this new keystore. I was never able to successfully import the keys into the existing keystore.
For example, on my ubuntu server, my keys are:
SSLCertificateFile /etc/apache2/ssl/star_astracorp_com.crt
SSLCertificateKeyFile /etc/apache2/ssl/star_astracorp_com.key
SSLCertificateChainFile /etc/apache2/ssl/astracorp.com.intermediate.sha1.chcrt
I then export the key as pkcs12:
openssl pkcs12 -export -in /etc/apache2/ssl/star_astracorp_com.crt -inkey /etc/apache2/ssl/star_astracorp_com.key -out server.p12 -name emsu1 -CAfile ca.crt -caname root
I then import the pkcs12 into a new java keystore:
keytool -importkeystore -deststorepass password -destkeypass password -destkeystore server.keystore -srckeystore /etc/apache2/ssl/server.p12 -srcstoretype PKCS12 -srcstorepass password -alias emsu1
Then, in my apachemq directory I move the old broker.ks out of the way and rename server.keystore as kroker.ks and restart activemq.
One of my servers had .pem files for its keys. The process was still similar, however I had to go into OS X's keystore utility to get the password of the key.
openssl pkcs12 -export -in /etc/certificates/ems-dev.local.EDA65671FF2C9CE7DAA56E9AD8E4E5F3F2675C79.cert.pem -inkey /etc/certificates/ems-dev.local.EDA65671FF2C9CE7DAA56E9AD8E4E5F3F2675C79.key.pem -out server.p12 -name emsdev -CAfile ca.crt -caname root
you will then be asked for the key - copy and paste it from the key util.
Then, the process to create a new keystore is the same:
keytool -importkeystore -deststorepass password -destkeypass password -destkeystore server.keystore -srckeystore /etc/certificates/server.p12 -srcstoretype PKCS12 -srcstorepass password -alias emsdev
I cannot seem to configure Dropwizard to use ssl.
I've created a key
openssl genrsa -des3 -out server.key 1024
and a certificate
openssl req -new -key server.key -days 365 -out server.crt -x509
and imported it into a keystore
keytool -import -file server.crt -keystore keystore.jks
From there, I've placed the keystore.jks file into /src/main/resources, alongside the config.yaml file for dropwizard.
Then I tried configuring ssl for dropwizard according to the manual:
http:
ssl:
keyStore: ./keystore.jks
keyStorePassword: ********
However, when I navigate to the login page, it only works without https: and gives Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error when using https.
Are there other steps that I'm missing?
I posted on the mailing list and Codahale was quick to respond. I hadn't set nonblocking+ssl connectors in my configuration yaml file under the http: section. Putting in
connectorType: nonblocking+ssl
fixed everything. Thanks dropwizard wizard!
I am trying to enable two way ssl authentication between Apache Ace and management agent(by following the document http://ace.apache.org/dev-doc/design/using-client-certificates.html). To achieve this , first of all i created the required certificates by following the steps mentioned below:
Step#1) Created a self-signed certificate authority using OpenSSL by excecuting the command below:
openssl req -x509 -new -config Certi/X509CA/openssl.cnf -days 365 -out Certi/X509CA/ca/new_ca.pem -keyout Certi/X509CA/ca/new_ca_pk.pem
This command created a certificate new_ca.pem and its private key new_ca_pk.pem.
Step#2) Imported the certificate new_ca.pem to keystore file named truststore by using following command
keytool -import -alias truststore -keystore truststore -file new_ca.pem
Step#3) Created certificate for the management agent, available in a Java keystore file, called keystore-ma.jks.
keytool -genkey -dname "CN=<hostIP>, OU=IT, O=<Organization Name>, ST=UP, C=IN" -validity 365 -alias keystore-ma -keypass secret -keystore keystore-ma.jks -storepass secret
Step#4) Created a CSR:
keytool -certreq -alias keystore-ma -file keystore-ma_csr.pem -keypass secret -keystore keystore-ma.jks -storepass secret
Step#5) Signed the certificate using the certificate authority created in Step 1.
openssl ca -config X509CA/openssl.cnf -days 365 -cert C:/X509CA/ca/new_ca.pem -keyfile C:/X509CA/ca/new_ca_pk.pem -in C:/X509CA/ca/keystore-ma_csr.pem -out C:/X509CA/ca/keystore-ma.pem
Step#6) Imported the certificate in a kestore file named keystore-ma
keytool -import -alias keystore-ma -keystore keystore-ma -file keystore-ma.pem
Similar steps(3-6) were followed to create and sign the cetificate or the ACE server, available in a Java keystore file, called keystore-server.
Then i updated the Platform.properties of Ace Server to include the additional properties and started Ace Server:
-Dorg.osgi.service.http.port.secure=8443
-Dorg.apache.felix.https.enable=true
-Dorg.apache.felix.https.truststore=/path/to/truststore
-Dorg.apache.felix.https.truststore.password=secret
-Dorg.apache.felix.https.keystore=/path/to/keystore-server
-Dorg.apache.felix.https.keystore.password=secret
-Dorg.apache.felix.https.clientcertificate=needs
Started ace-launcher.jar with the following command:
java -Djavax.net.ssl.trustStore=/path/to/truststore -Djavax.net.ssl.trustStorePassword=secret -Djavax.net.ssl.keyStore=/path/to/keystore-ma -Djavax.net.ssl.keyStorePassword=secret -jar org.apache.ace.launcher-0.8.1-SNAPSHOT.jar discovery=https://<Ace Server Ip>:8443 identification=MyTarget
i tried multiple times by changing the discovery url to
1) https://<Ace Server Ip>:8080
2) http://<Ace Server Ip>:8080
3) https://<Ace Server Ip>:8443
But the target was not registered in the Ace Server. Am i using the correct URLs to connect to Ace server through HTTPS?
Also how to confirm if my Ace Server is configured to accept HTTPS traffic from the management agent?
I see you use a distinguished name (DN) with more than only a common name.
By convention, the hostname as common name is used for certificate validation. It should work if you create a certificate with CN=hostname-of-target (IP address is not sufficient).
Another hint I can give you for troubleshooting SSL errors: use -Djavax.net.debug=ssl for the server, it will spit out lots of information, but gives detailed information on what is going on and what causes the error.
I am trying to configure SSL on my Jetty.
I read this:
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
and created a key store.
Then, I jumped directly to section 4. But where is this configuration file I should configure Jetty?
I tried to serach for jetty.xml, but there is no such on my computer...
I had a lot of problems making it work but I finally foud out how to make it happend. I'm using ubuntu 10.04 with java 7. It may be possible to do it under windows but all the comands lines are bash commands, maybe possible to do the same with cigwin/mingw
I used Jetty 8.1.8. Download it from codehaus and choose the .tar.gz file for linux (.zip for windows).
Unzip the file in any directory you wish, this will be your {jetty} home folder for the sake of this article/answer.
Go to the {jetty}/etc directory.
Execute all the following command lines in order. Whenever a password is asked, input the same password all the time. The passwords are used to protect the key file, the key store and the certificate itself. Sometimes, a password will be asked to unlock the key store or to use a generated key. Once you will understand what everything is and how to use the passwords correctly, you may change those passwords when you feel ready (safer for production use). Otherwise, input the requested informations when asked.
openssl genrsa -des3 -out jetty.key
openssl req -new -x509 -key jetty.key -out jetty.crt
keytool -keystore keystore -import -alias jetty -file jetty.crt -trustcacerts
openssl req -new -key jetty.key -out jetty.csr
openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
Now you have to edit {jetty}/etc/jetty-ssl.xml and configure your password to match the one you used during certificate generation. If you want to obfuscate your password, go back to the command line. Go tho your {jetty} home directory and execute the following:
java -cp lib/jetty-util-8.1.8.v20121106.jar org.eclipse.jetty.util.security.Password "{PASSWORD}"
Change {PASSWORD} for your actual password then past the obfuscated password, including the "OBF:" in all password fields found in jetty-ssl.xml. Note that a password obfuscated like that is hard to read for humans but easily unobfiscated programmatically. It just prevent developpers to know the password when they edit the file. All configuration files should be secured properly and their accesses be as restrictive as possible.
Edit {jetty}/start.ini and uncomment the line #etc/jetty-ssl.xml (just remove the #).
Start jetty:
java -jar start.jar
Now contact your server at: https://localhost:8443
Done!
Note that this answer is a quick way to enable SSL with jetty. To make it secure for production, you have to read some more on the subject.
Answer updated after more experience with keystores. I assure you this solution works perfectly with intermediate certificates (29/07/2015).
Note: PEM format means a readable file, certificates start with ---BEGIN CERTIFICATE--- and private keys start with -----BEGIN PRIVATE KEY----- line.
Here's an easy step by step guide. Start with an empty directory.
Skip to Step 2 if you have private key (PEM encoded .key)
Skip to Step 3 if you have certificate signing request (PEM encoded .csr)
Skip to Step 4 if you have your certificate (PEM encoded .crt or .pem)
Prepare (password-less) private key.
openssl genrsa -des3 -passout pass:1 -out domain.pass.key 2048
openssl rsa -passin pass:1 -in domain.pass.key -out domain.key
rm domain.pass.key
Prepare certificate signing request (CSR). We'll generate this using our key. Enter relevant information when asked. Note the use of -sha256, without it, modern browsers will generate a warning.
openssl req -key domain.key -sha256 -new -out domain.csr
Prepare certificate. Pick one:
a) Sign it yourself
openssl x509 -req -days 3650 -in domain.csr -signkey domain.key -out domain.crt
b) Send it to an authority
Your SSL provider will supply you with your certificate and their intermediate certificates in PEM format.
Add to trust chain and package it in PKCS12 format. First command sets a keystore password for convenience (else you'll need to enter password a dozen times). Set a different password for safety.
export PASS=LW33Lk714l9l8Iv
Pick one:
a) Self-signed certificate (no need for intermediate certificates)
openssl pkcs12 -export -in domain.crt -inkey domain.key -out domain.p12 -name domain -passout pass:$PASS
keytool -importkeystore -deststorepass $PASS -destkeypass $PASS -destkeystore domain.keystore -srckeystore domain.p12 -srcstoretype PKCS12 -srcstorepass $PASS -alias domain
b) Need to include intermediate certificates
Download intermediate certificates and concat them into one file. The order should be sub to root.
cat sub.class1.server.ca.pem ca.pem > ca_chain.pem
Use a -caname parameter for each intermediate certificate in chain file, respective to the order they were put into the chain file.
openssl pkcs12 -export -in domain.crt -inkey domain.key -out domain.p12 -name domain -passout pass:$PASS -CAfile ca_chain.pem -caname sub1 -caname root -chain
keytool -importkeystore -deststorepass $PASS -destkeypass $PASS -destkeystore domain.keystore -srckeystore domain.p12 -srcstoretype PKCS12 -srcstorepass $PASS -alias domain
Important note: Although keytool -list will only list one entry and not any intermediate certificates, it will work perfectly.
Configure jetty.
Move domain.keystore file to JETTY_HOME/etc/.
Pick one:
a) You're using new start.ini style configuration (Jetty 8+):
jetty.keystore=etc/domain.keystore
jetty.truststore=etc/domain.keystore
jetty.keystore.password=LW33Lk714l9l8Iv
jetty.keymanager.password=LW33Lk714l9l8Iv
jetty.truststore.password=LW33Lk714l9l8Iv
b) You're using old style configuration with .xml files (you should upgrade to new style!):
Edit JETTY_HOME/etc/jetty-ssl.xml file and change the part below. Replace password parts to match your password. We don't define KeyManagerPassword because our key has no password.
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<New id="sslContextFactory" class="org.eclipse.jetty.http.ssl.SslContextFactory">
<Set name="KeyStore"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="KeyStorePassword">LW33Lk714l9l8Iv</Set>
<Set name="TrustStore"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="TrustStorePassword">LW33Lk714l9l8Iv</Set>
</New>
<Call name="addConnector">...</Call>
</Configure>
Edit start.ini file to include jetty-ssl.xml file.
(Re)start jetty.
Note that this keystore file can also be used with other containers like Tomcat. Good luck!
A default configuration file for Jetty and is located at $JETTY_HOME/etc/jetty.xml
If you are using maven's jetty plugin you will need to specify ssl keystore details in your pom.xml file. See this question for details
Just bought a cert from godaddy for mere $6/year. Great deal while it lasts. Here are the steps I followed to set it up on Amazon EC2/Ubuntu/Jetty based on these sites and Jean-Philippe Gravel's answer.
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
http://community.xmatters.com/docs/DOC-1228#.UgWsI1MU7lc
keytool -keystore keystore -alias jettykey -genkey -keyalg RSA
Note that "First and last name" must be your FQDN (without http://). On my first attempt I had dutifully put my first and last name, but godaddy has good warnings and rejected it.
Generate a CSR file for Godaddy:
keytool -certreq -alias jetty -keystore keystore -file jetty.csr
Submit this in the Godaddy form to create the certificate, including the BEGIN/END "NEW CERTIFICATE REQUEST".
(Godaddy requires you to verify its your site. There a couple methods for this and since I bought the domain name via a proxy, I found it easiest and quickest to verify by hosting an html page generated by godaddy.)
Download the zip containing both certificate and intermediary certificate from godaddy. There is a list of server types to choose from. I choose "other". Then combine cert with intermediary cert.
cat mydomain.com.crt gd_bundle.crt > certchain.txt
export my private key
keytool -importkeystore -srckeystore keystore -destkeystore intermediate.p12 -deststoretype PKCS12
openssl pkcs12 -in intermediate.p12 -out jettykey.pem -nodes
combine private key and certificate
openssl pkcs12 -export -inkey jettykey.pem -in certchain.txt -out jetty.pkcs12
import pkcs12 cert (alias becomes 1)
keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
(I backed up the keystore then deleted the original key. I did this while troubleshooting and this may or may not be required by Jetty.)
keytool -delete -keystore keystore -alias jettykey
sudo cp keystore /usr/share/jetty/etc/
sudo vi /usr/share/jetty/etc/jetty-ssl.xml
Modify your.store.password, your.key.password, and your.trust.password accordingly. If you want to obfuscate it, use
java -cp /usr/share/jetty/lib/jetty.jar:/usr/share/jetty/lib/jetty-util.jar org.mortbay.jetty.security.Password <your.password>
Indicate to Jetty to load the jetty-ssl.xml file.
sudo echo "/etc/jetty/jetty-ssl.xml" >> /etc/jetty/jetty.conf
sudo /sbin/iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
(Also modify Amazon EC2 security group to allow 443)
sudo service jetty start
If you happen to work with Jetty 9.3 then you should change configuration in start.d/ssl.ini:
jetty.sslContext.keyStorePath=mystore.jks
jetty.sslContext.keyStorePassword=X
jetty.sslContext.keyManagerPassword=X
jetty.sslContext.trustStorePath=mystore.jks
jetty.sslContext.trustStorePassword=X
Where:
mystore.jks is your store generated with the keytool
X is your password in plain text (I would recommend skipping obfuscation as it only gives you false security)
The store is exactly the same as you would generate for Tomcat. Even if you used different Java version to generate the keystore that should not be a problem.
When trying on Windows with Jetty as Maven plugin the following steps can help:
pom.xml
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>8.1.11.v20130520</version>
<configuration>
<scanIntervalSeconds>10</scanIntervalSeconds>
<webApp>
<contextPath>/yourappcontext</contextPath>
</webApp>
<connectors>
<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
<port>9090</port>
<maxIdleTime>1</maxIdleTime>
</connector>
<connector implementation="org.eclipse.jetty.server.ssl.SslSocketConnector">
<port>9443</port>
<keystore>src/test/resources/keystore</keystore>
<keyPassword>123456</keyPassword>
<password>123456</password>
</connector>
</connectors>
</configuration>
</plugin>
Generate key/certificate using the JDK tool keytool:
keytool -keystore keystore -alias jetty -genkey -keyalg RSA
This command will generate a file keystore which we need to put at the following (or what ever you like until it is configured in the keystore element) path src/test/resources/keystore.