I cannot get Rundeck to start with SSL - ssl

I installed Rundeck on a new RHEL 7.7 box, using the rpm method. I can access the server just fine with http, but when I follow the directions in the docs, the server is not accessible from browsers or by curling localhost.
The only error I receive is:
WARN SslContextFactory --- [ main] No supported ciphers from [SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,...(many more ciphers)
Grails application running at https://localhost:4443 in environment: production
curl localhost:4443
curl: (35) Peer reports it experienced an internal error.
Relevant parts of the configuration files are as follows:
/etc/rundeck/profile:
RDECK_JVM="-Drundeck.jaaslogin=$JAAS_LOGIN \
-Djava.security.auth.login.config=$JAAS_CONF \
-Dloginmodule.name=$LOGIN_MODULE \
-Drdeck.config=$RDECK_CONFIG \
-Drundeck.server.configDir=$RDECK_SERVER_CONFIG \
-Dserver.datastore.path=$RDECK_SERVER_DATA/rundeck \
-Drundeck.server.serverDir=$RDECK_INSTALL \
-Drdeck.projects=$RDECK_PROJECTS \
-Drdeck.runlogs=$RUNDECK_LOGDIR \
-Drundeck.config.location=$RDECK_CONFIG_FILE \
-Djava.io.tmpdir=$RUNDECK_TEMPDIR \
-Drundeck.server.workDir=$RUNDECK_WORKDIR \
-Dserver.http.port=$RDECK_HTTP_PORT \
-Drdeck.base=$RDECK_BASE \
-Djdk.tls.ephemeralDHKeySize=jdk8 \
-Drundeck.rundeck.jetty.connector.ssl.excludedCipherSuites=SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384,SSL_RSA_WITH_AES_256_CBC_SHA256,SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384,SSL_DHE_RSA_WITH_AES_256_CBC_SHA256,SSL_DHE_DSS_WITH_AES_256_CBC_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA,SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA,SSL_ECDH_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_DSS_WITH_AES_256_CBC_SHA,SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256,SSL_RSA_WITH_AES_128_CBC_SHA256,SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256,SSL_DHE_RSA_WITH_AES_128_CBC_SHA256,SSL_DHE_DSS_WITH_AES_128_CBC_SHA256,SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA,SSL_ECDH_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384,SSL_RSA_WITH_AES_256_GCM_SHA384,SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384,SSL_DHE_DSS_WITH_AES_256_GCM_SHA384,SSL_DHE_RSA_WITH_AES_256_GCM_SHA384,SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256,SSL_DHE_RSA_WITH_AES_128_GCM_SHA256,SSL_DHE_DSS_WITH_AES_128_GCM_SHA256"
#
# Set min/max heap size
#
RDECK_JVM="$RDECK_JVM $RDECK_JVM_SETTINGS"
#
# SSL Configuration - Uncomment the following to enable. Check SSL.properties for details.
#
if [ -n "$RUNDECK_WITH_SSL" ] ; then
RDECK_JVM="$RDECK_JVM -Drundeck.ssl.config=$RDECK_SERVER_CONFIG/ssl/ssl.properties -Dserver.https.port=${RDECK_HTTPS_PORT} -Dorg.eclipse.jetty.util.ssl.LEVEL=DEBUG"
fi
/etc/sysconfig/rundeckd:
export RUNDECK_WITH_SSL=true
export RDECK_HTTPS_PORT=4443
If I add export RDECK_JVM_OPTS="-Dserver.ssl.ciphers=SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384" to /etc/sysconfig/rundeckd I get the following:
[2020-03-29 09:01:51.533] WARN config --- [ main] Weak cipher suite SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 enabled for SslContextFactory#1456dec8[provider=null,keyStore=file:///etc/rundeck/ssl/keystore,trustStore=file:///etc/rundeck/ssl/truststore]
Grails application running at https://localhost:4443 in environment: production
curl: (35) Peer reports it experienced an internal error.
Other configurations:
/etc/rundeck/framework.properties:
framework.server.name = server-dns
framework.server.hostname = server-dns
framework.server.port = 4443
framework.server.url = https://server-dns
framework.rundeck.url = https://server-dns
/etc/rundeck/rundeck-config.properties:
grails.serverURL=https://server-dns:4443
keystore and truststore exist, I have attempted both self signed and real crts.
I'm at a loss here. I followed all sorts of guides and advice from the internet leading to my current (mis?)configuration.
Thanks
Edited to fix mistakes in the post.

Maybe you need to reference your keystore/trustore in ssl.properties file (usually at /etc/rundeck/ssl/ssl.properties path). I wrote a little guide to set up Rundeck with SSL.
1.- install Rundeck.
rpm -Uvh https://repo.rundeck.org/latest.rpm
yum install rundeck
2.- create keystore: (if you already have a certificate in .key/.crt or .pk12 formats, skip to 2b)
keytool -keystore /etc/rundeck/ssl/keystore -alias rundeck -genkey -keyalg RSA -keypass password -storepass password
2b.- in case you have your own certificate, do below:
If you have .crt and .key files, create a .p12 file:
openssl pkcs12 -export -in YOUR.crt -inkey YOUR.key -out NEW.p12
Convert it to a .jks (also if you have only the .p12 file):
keytool -importkeystore -destkeystore keystore -srckeystore NEW.p12 -srcstoretype pkcs12
3.- copy keystore as truststore.
4.- edit /etc/rundeck/ssl/ssl.properties file:
keystore=/etc/rundeck/ssl/keystore
keystore.password=password
key.password=password
truststore=/etc/rundeck/ssl/truststore
truststore.password=password
5.- edit /etc/rundeck/framework.properties file:
framework.server.port = 4443
framework.server.url = https://localhost:4443
6.- edit /etc/rundeck/rundeck-config.properties file:
grails.serverURL=https://localhost:4443
7.- edit/create /etc/sysconfig/rundeckd file:
export RUNDECK_WITH_SSL=true
8.- start the rundeck service.
systemctl start rundeckd

Related

configuring TLS CA on Databricks

I am trying to call an aricGIS service for GEOCoding from Databricks. The URL needs a certificate which i have copied to Blob storage and referring to that in the
Verify = "Path to mycertificate"
section of the code.
the certificate is stored in the following location
/dbfs/mnt/tmp/myfolder/mycertificate.pem
When accessing the certificate from the above path i am getting a HTTP error as below
SSLError: HTTPSConnectionPool(host='MyDomain.com', port=443): Max retries exceeded with url: "MyURL" (Caused by SSLError(SSLEOFError(8, 'EOF occurred in violation of protocol (_ssl.c:1131)')))
when changing the above certificate path from
/dbfs/...
To
dbfs:/Path/To/Mycertificate
I get the following Error
OSError: Could not find a suitable TLS CA certificate bundle, invalid path: dbfs:/mnt/tmp/path/to/mycertificate.pem
I have also tried the operation with the .pfx file but getting the same error.
Being new to the Certificates in Databricks any help on how to fix the errors and get the service working would be really appreciated.
Also i have googled and referred to many documents to no avail. Nothing is working and it appears i am missing something basic here.
Thanks
To fix this, SSL Certificate needs to be installed on the cluster nodes. For Python this could be two locations:
Linux CA Certificates chain for most of SSL connections
CA Certificates chain that is used by the requests package - provided by certifi package.
You can install the certificates using the following cluster init script that will install your CA certificate in PEM format into all CA certificate chains (Linux/Java/certifi) (you need to put your path /dbfs/.... into the certs variable):
#!/bin/bash
#
# File: install-ssl-certificates.sh
# Author: Alex Ott
# Created: Tuesday, September 28 2021
#
#set -x
declare -a certs=("/dbfs/tmp/myCA.pem" "/dbfs/tmp/myCA2.pem")
mkdir -p /usr/share/ca-certificates/extra
CERTIFI_HOME="$(python -m certifi 2>/dev/null)"
J_HOME="$(dirname $(realpath $(which java)))/.."
for cert in ${certs[#]}; do
BNAME="$(basename $cert)"
echo "cert=$cert BNAME=$BNAME"
cp $cert /usr/share/ca-certificates/extra/$BNAME
echo "extra/$BNAME" >> /etc/ca-certificates.conf
if [ -n "$CERTIFI_HOME" ]; then
cat $cert >> $CERTIFI_HOME
fi
keytool -importcert -keystore ${J_HOME}/lib/security/cacerts -file $cert -alias $(basename $cert .pem) -storepass changeit -noprompt
done
update-ca-certificates
I have found that the firewall was blocking the request. The solution was to just unblock the target IP address on the firewall and providing a certificate location to ".pem" file in the url in the format
session.post(url,data=d,verify=\path to my certificate.pemfile)
that resolved the issue.
Thanks

Apache kafka consumer java.security.cert.CertificateException: No subject alternative names present

I'm trying to connect to remove kafka broker as consumer using 0.11.0.3 kafka version via SSL using commandline tool, connection string is the following
kafka-console-consumer.bat \
--bootstrap-server host:port \
--topic topicName \
--from-beginning \
--group groupId \
--consumer.config ssl.properties
ssl.properties file
security.protocol=SSL
ssl.truststore.location=path/to/truststore.jks
ssl.truststore.password=1234567
ssl.keystore.location=path/to/keystore.jks
ssl.keystore.password=1234567
ssl.key.password=1234567
ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
ssl.truststore.type=JKS
ssl.keystore.type=JKS
Exception I get
[2020-04-28 17:24:39,522] ERROR [Consumer clientId=consumer-1, groupId=binomix] Connection to node -1 (/178.208.149.84:9301) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2020-04-28 17:24:39,524] ERROR Error processing message, terminating consumer process: (kafka.tools.ConsoleConsumer$)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1582)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:544)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1216)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1184)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
at org.apache.kafka.common.network.SslTransportLayer.handshakeWrap(SslTransportLayer.java:448)
at org.apache.kafka.common.network.SslTransportLayer.doHandshake(SslTransportLayer.java:313)
at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:265)
at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:170)
at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:547)
at org.apache.kafka.common.network.Selector.poll(Selector.java:483)
at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:535)
at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:265)
at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:236)
at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:215)
at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureCoordinatorReady(AbstractCoordinator.java:235)
at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:317)
at org.apache.kafka.clients.consumer.KafkaConsumer.updateAssignmentMetadataIfNeeded(KafkaConsumer.java:1226)
at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1191)
at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1176)
at kafka.tools.ConsoleConsumer$ConsumerWrapper.receive(ConsoleConsumer.scala:439)
at kafka.tools.ConsoleConsumer$.process(ConsoleConsumer.scala:105)
at kafka.tools.ConsoleConsumer$.run(ConsoleConsumer.scala:77)
at kafka.tools.ConsoleConsumer$.main(ConsoleConsumer.scala:54)
at kafka.tools.ConsoleConsumer.main(ConsoleConsumer.scala)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:333)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1689)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:1015)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:1012)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1520)
at org.apache.kafka.common.network.SslTransportLayer.runDelegatedTasks(SslTransportLayer.java:402)
at org.apache.kafka.common.network.SslTransportLayer.handshakeUnwrap(SslTransportLayer.java:484)
at org.apache.kafka.common.network.SslTransportLayer.doHandshake(SslTransportLayer.java:340)
... 18 more
Caused by: java.security.cert.CertificateException: No subject alternative names present
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:145)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:459)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:440)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:284)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1676)
... 27 more
Processed a total of 0 messages
Any ideas why it happens? Is it an issue with certificates? I did not generate them, they were given me by kafka server owner.
Thanks in advance.
It seems that Subject Alternative Name (SAN) is missing from your brokers' certificates (for example /var/private/ssl/kafka.server.truststore.jks).
To do so, append the argument -ext SAN=DNS:{FQDN} to the keytool command:
keytool \
-keystore kafka.server.keystore.jks \
-alias localhost \
-validity {validity} \
-genkey \
-keyalg RSA \
-ext SAN=DNS:{FQDN}
Make sure to inclued SAN when creating servers' keystores. This is also mentioned in the Confluent's Security Tutorial:
If host name verification is enabled, clients will verify the server’s
fully qualified domain name (FQDN) against one of the following two
fields:
Common Name (CN)
Subject Alternative Name (SAN)
Both fields are valid, however RFC-2818 recommends the use of SAN. SAN is also more flexible,
allowing for multiple DNS entries to be declared. Another advantage is
that the CN can be set to a more meaningful value for authorization
purposes.
Alternatively, you can choose to disable server host verification:
Disable server host name verification by setting
ssl.endpoint.identification.algorithm to an empty string.
Therefore, you just need to set in server.properties the following configuration and finally restart your Kafka Cluster:
ssl.endpoint.identification.algorithm=
Please note that inclusion of the 'SAN' when generating the key-pair (and hence the key-store) is not enough.
keytool \
-keystore kafka.server.keystore.jks \
-alias {alias} \
-validity {validity} \
-genkey \
-keyalg RSA \
-ext SAN=DNS:{FQDN}
This needs to be followed by inclusion of the 'SAN' when creating the certificate signing request as well.
keytool \
-keystore kafka.server.keystore.jks \
-alias {alias} \
-certreq -ext SAN=DNS:{FQDN}
-file {csr_filename}
One can verify the certificate signing request thus created, and it should have the relevant SAN present.
keytool \
-v -printcertreq -file {csr_filename}
Later, if openssl's x509 command is used to fulfil the certificate signing request, care should be taken to explicitly include the x509 version 3 extensions. The 'SAN' is one such extension and unless explicitly included, will not find its way into the certificate that is finally issued.
The concept is discussed in detail here - Subject Alternative Name not present in certificate.

How to install letsencrypt free ssl to glassfish 4.x server

I have scanned SO and found there is no detailed instructions on how to install letsencrypt.org SSL certificate on glassfish and specifically in this tutorial I will be using glassfish 4.1.2 build 1. After a lot of trial and error, I was able to put together the following guide. So I hope that it is fine to ask and answer my own question.
In this tutorial I shall be using an Ubuntu 16.04 LTS Server with Shell access from my Ubuntu 16.04 LTS desktop.
visit certbot and follow the instructions below to setup your system
Install
On Ubuntu systems, the Certbot team maintains a PPA. Once you add it to your
list of repositories all you'll need to do is apt-get the following packages.
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot
Get Started
Since your server architecture doesn't yet support automatic installation
you'll have to use the certonly command to obtain your certificate.
$ sudo certbot certonly
terminal will output
Saving debug log to /var/log/letsencrypt/letsencrypt.log
How would you like to authenticate with the ACME CA?
1: Place files in webroot directory (webroot)
2: Spin up a temporary webserver (standalone)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
We select the 1st option key in 1 and press enter
terminal will output
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel):yoursite.com www.yoursite.com
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for yoursite.com
http-01 challenge for www.yoursite.com
terminal will output
Select the webroot for yoursite.com:
1: Enter a new webroot
Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
Input the webroot for yoursite.com: (Enter 'c' to cancel):/home/yourUsername/glassfish4/glassfish/domains/domain1/docroot
Select the webroot for www.yoursite.com:
1: Enter a new webroot
2: /home/yoursite/glassfish4/glassfish/domains/domain1/docroot
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem
terminal will output
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/yoursite.com/fullchain.pem. Your cert will
expire on 2017-08-21. To obtain a new or tweaked version of this
certificate in the future, simply run certbot again. To
non-interactively renew *all* of your certificates, run "certbot
renew"
Automating renewal
The Certbot packages on your system come with a cron job that will renew your certificates automatically before they expire. Since Let's Encrypt certificates last for 90 days, it's highly advisable to take advantage of this feature. You can test automatic renewal for your certificates by running this command:
certbot renew --dry-run
make the following script can automate importing certificate to glassfish
for further reading
https://community.letsencrypt.org/t/importing-letsencrypt-into-java-and-glassfish/9711
Now we import the certificates.
Make the following script and save it as yourscriptname.sh to automate the process then run it with the command
$ sh yourscriptname.sh
#!/bin/sh
DOMAIN=yoursite.com
#note that changeit is the default keystore password
KEYSTOREPW=changeit
GFDOMAIN=/home/yourUsername/glassfish4/glassfish/domains/domain1
LIVE=/etc/letsencrypt/live/$DOMAIN
mkdir etc
cd etc
sudo openssl pkcs12 -export -in $LIVE/cert.pem -inkey $LIVE/privkey.pem -out cert_and_key.p12 -name myalias -CAfile $LIVE/chain.pem -caname root -password pass:$KEYSTOREPW
sudo keytool -importkeystore -destkeystore keystore.jks -srckeystore cert_and_key.p12 -srcstoretype PKCS12 -alias myalias -srcstorepass $KEYSTOREPW -deststorepass $KEYSTOREPW -destkeypass $KEYSTOREPW
sudo keytool -import -noprompt -trustcacerts -alias root -file $LIVE/chain.pem -keystore keystore.jks -srcstorepass $KEYSTOREPW -deststorepass $KEYSTOREPW -destkeypass $KEYSTOREPW
sudo openssl pkcs12 -export -in $LIVE/fullchain.pem -inkey $LIVE/privkey.pem -out pkcs.p12 -name glassfish-instance -password pass:$KEYSTOREPW
sudo keytool -importkeystore -destkeystore keystore.jks -srckeystore pkcs.p12 -srcstoretype PKCS12 -alias glassfish-instance -srcstorepass $KEYSTOREPW -deststorepass $KEYSTOREPW -destkeypass $KEYSTOREPW
sudo openssl pkcs12 -export -in $LIVE/fullchain.pem -inkey $LIVE/privkey.pem -out pkcs.p12 -name s1as -password pass:$KEYSTOREPW
sudo keytool -importkeystore -destkeystore keystore.jks -srckeystore pkcs.p12 -srcstoretype PKCS12 -alias s1as -srcstorepass $KEYSTOREPW -deststorepass $KEYSTOREPW -destkeypass $KEYSTOREPW
sudo keytool -list -keystore keystore.jks -storepass $KEYSTOREPW
sudo cp -f keystore.jks $GFDOMAIN/config/
sudo service glassfish stop
sudo service glassfish start
cd ..
sudo rm -rf etc
if you need to change the keystore password
Use keytool command. If it doesn't work you might have to cd to the path where it's located in your glassfish-install-dir/glassfish/domains/domain1/config directory and run the command in that directory.
keytool -storepasswd -keystore /path/to/keystore
Enter keystore password: changeit
New keystore password: new-password
Re-enter new keystore password: new-password
After successfully importing the certs and restarting glassfish server, SSL worked with the installed web application but unfortunately I was not able to log into the glassfish admin console from the browser, though the asadmin tool still worked.
solving unable to login to admin console after above changes
We need to add wget command to our script to download the most Recent CA file revisions per date of apperance from recent trusted ca revisions from mozilla
Add the following to the the yourname.sh script just above the command sudo service glassfish stop to fix the problem.
wget https://curl.haxx.se/ca/cacert-2017-01-18.pem --no-check-certificate -O cacert.pem
PEM_FILE=cacert.pem
KEYSTORE=cacerts.jks
CERTS=$(grep 'END CERTIFICATE' $PEM_FILE| wc -l)
for N in $(seq 0 $(($CERTS -1))); do
ALIAS="${PEM_FILE%.*}-$N"
cat $PEM_FILE | awk "n==$N { print }; /END CERTIFICATE/ { n++ }" |
keytool -noprompt -import -trustcacerts \
-alias $ALIAS -keystore $KEYSTORE -storepass $KEYSTOREPW
done
sudo keytool -list -keystore keystore.jks -storepass $KEYSTOREPW
sudo keytool -list -keystore cacerts.jks -storepass $KEYSTOREPW
if [ ! -f $GFDOMAIN/config/keystore-orig.jks ]; then
echo "Backing up original files..."
sudo cp -f $GFDOMAIN/config/keystore.jks $GFDOMAIN/config/keystore-orig.jks
sudo cp -f $GFDOMAIN/config/cacerts.jks $GFDOMAIN/config/cacerts-orig.jks
fi
echo "Updating certificates..."
sudo cp -f keystore.jks $GFDOMAIN/config/keystore.jks
sudo cp -f cacerts.jks $GFDOMAIN/config/cacerts.jks
cd ..
echo stop and restart glassfish domain to complete
cd ..
sudo rm -rf etc
I hope this helps someone cheers all!
I have created a Perl script to assist in the installation of Let's Encrypt certificates in Glassfish and Payara. I have successfully used it to not only install a certificate for multiple domains in about five minutes, but to automatically renew - via a cron job - those certificates when they were about to expire.
What I've done is broken the process of obtaining a Let's Encrypt certificate into the following steps, not all of which will be necessary:
Customize the script to the particular local installation
1a. List of domains for which a certificate is to be created
1b. Glassfish/Payara setup (where they're located in your filesystem)
1c. Password for Glassfish/Payara
Change Glassfish/Payara to listen on ports 80 and 443
Generate the Let's Encrypt certification keys
Insure that the keystore password matches that of the server
Create a keystore
Import the created keystore into the Glassfish/Payara keystore
Apply the new certificate to the https listener
Update the domain SSL information
Set (if necessary) the server admin password.
Set up the https domain
Additionally, the script can be invoked periodically (typically via 'cron') to check to see if any domains need to be renewed and if so, renew them automatically.
See: https://github.com/hbrednek/letsencrypt_glassfish for the script.

How to setup Dart to use a CA SSL certificate?

I recently deployed a Dart server application that serves HTTP requests. I wanted to add support for HTTPS so I have been trying to add SSL to the Dart server application.
This answer gives a clear explanation of how to add a self-signing SSL certificate to Dart. However, I want to add an SSL certificate I bought from an SSL provider.
The SSL provider e-mailed my 4 files:
Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
Your PositiveSSL Certificate - my_domain.crt
I have been trying to figure out how certutil works and how to add these certificates to the certificate database, but I just can't figure it all out.
Anyone with experience enabling a CA SSL certificate in Dart?
SOLVED: Thanks to suggestion in the comments, I solved the issue. This is the gist of my complete setup: https://gist.github.com/stevenroose/e6abde14258971eae982
First of all, you probably have three files generated with openssl for your private key, server certificate and CA certificate. To convert all those into a PKCS12 file, you can use openssl:
openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt -certfile CAcert.crt
Then, you can adapt the certutil commands as shown to load you PKCS12 instead of generating new certificates:
certutil -N -d sql:certdb
certutil -A -n mycertnick -i server.crt -t "TCu,Cu,Tuw" -d sql:certdb
certutil -A -n myCA -i CAcert.crt -t "TCu,Cu,Tuw" -d sql:certdb
pk12util -i server.p12 -d sql:certdb
It seems to work with the sample code in the referenced question.
Unfortunately the SSL management in Dart is known to be very lacking.
I reported this many times, with no serious answer from the Dart team.
Star this issue if you want something done about it:
https://code.google.com/p/dart/issues/detail?id=20967

Keystore password for Jetty 7.0 SSL configuration

Trying to setup SSL on jetty 7.2.2 using these instructions:
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
stuck on 3b:
keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore $JETTY_HOME/etc/keystore
jetty ships with default keystore at $JETTY_HOME/etc/keystore. I'm asked for password when running that command. I don't know default keystore password.
If I try to replace that keystore with newly created one - I'm getting IOException on jetty startup - keystore is tampered with or password incorrect.
What I'm doing wrong? Or what's default keystore jetty password?
The default password for the keystore that is shipped with jetty is storepwd. But I would highly recommend you follow the steps listed in the How to configure SSL and create your own keystore.
I think you just want to overwrite the keystore in etc/keystore with your new one. Then, update the Jetty conf as in Step 4. You will need to obfuscate your keystore password using the org.mortbay.jetty.security.Password class.
One more subtle steps that needs to be followed .
i.e Jetty has another file start.ini, un-comment jetty-ssl.xml line to make the SSL configuration active.
That was my bad. Didn't notice that there's jetty-ssl.xml also, that used default keystore. Moved addConnector to jetty-ssl.xml, put right passwords there, and everything works now like a charm.
One note, the eclipse version of jetty works a little differently http://www.eclipsezone.com/eclipse/forums/t88098.html
Today with jetty 9.4.34 and you'd like to use the default keystore password storepwd and default private key password keypwd, so that you don't have to modify the config, and you have cert/key in common PEM format...
tmpcert="/tmp/certkey$RANDOM.pkcs12" ; \
openssl pkcs12 -export -inkey "key.pem" \
-in "cert.pem" \
-passout "pass:storepwd" \
-out "$tmpcert" \
&& \
keytool -importkeystore \
-srckeystore "$tmpcert" -srcstoretype PKCS12 \
-srcstorepass storepwd \
-destkeystore "$JETTY_BASE/etc/keystore" -deststoretype JKS \
-deststorepass storepwd \
-destkeypass keypwd ; \
rm "$tmpcert"
That's all you need to import to provide SSL functionality
Because of JKS there is the
Warning: The JKS keystore uses a proprietary format. It is recommended
to migrate to PKCS12 which is an industry standard format using
...
But it is the only possibility to set a different keypass like keypwd for key and storepwd for keystore.
For pkcs12 storetype this distinction is impossible (at least with keytool, there is an error on execution).
For the rest (like config modifications for own passwords, and generating own passwords) the documentation at https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html is ok.