Firefox 54 Stopped Trusting Self-Signed Certs - ssl

With the recent upgrade of Firefox 54, my self-signed localhost SSL certificate stopped being trusted.
I've been using a Firefox AutoConfigure script to install this certificate, and the technique has been working successfully for several years. Firefox uses its own certificate store, cert8.db which contains the certificate, verified using Firefox Preferences, Advanced, Certificates, View Certificates, Authorities.
This is reproducible on both MacOS as well as Windows. I've attached a sample certificate for reference. This is identical to one we would install.
What changed in Firefox 54? I've reviewed the changelog and can't find anything specific to how it trusts certificates.
Edit: Link to Firefox bug that most likely introduced this change: firefox #1294580
-----BEGIN CERTIFICATE-----
MIID/DCCAuSgAwIBAgIEDZj+fTANBgkqhkiG9w0BAQsFADCBmjELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAk5ZMRIwEAYDVQQHEwlDYW5hc3RvdGExGzAZBgNVBAoTElFa
IEluZHVzdHJpZXMsIExMQzEbMBkGA1UECxMSUVogSW5kdXN0cmllcywgTExDMRww
GgYJKoZIhvcNAQkBFg1zdXBwb3J0QHF6LmlvMRIwEAYDVQQDEwlsb2NhbGhvc3Qw
HhcNMTcwMjEyMDMzMjEwWhcNMzcwMjEyMDMzMjEwWjCBmjELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAk5ZMRIwEAYDVQQHEwlDYW5hc3RvdGExGzAZBgNVBAoTElFaIElu
ZHVzdHJpZXMsIExMQzEbMBkGA1UECxMSUVogSW5kdXN0cmllcywgTExDMRwwGgYJ
KoZIhvcNAQkBFg1zdXBwb3J0QHF6LmlvMRIwEAYDVQQDEwlsb2NhbGhvc3QwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCemwdWhvytOwhsRyEo/9ck3nKP
oBvMdkaiXKbMWlYZfYyb/EsJzw/LiEqGGhflWjneQLcgq0nuTtRaA9cm/vgPtVRX
OHewJeYBI2C4avJyjdFfQYHJKxuLi3nwmZ5JwcDm04H6SADwdyQuYB4AFr32uY5D
3id0gyDV+EX9sSOPThtdBpEbaBcFmAdAGdQUCzSJyi4Yu6UkIs7OPBHp9lOvm8VQ
r6ZVnqdFEXmxgpgMS0sQwDwZnBB3hFcVmE/sYy+2gV/h+yvRUjgqwC/SoLh9f4D0
eG19E3OEmsSyFM9K2Wl4ltOE/Aq1KFm7dPw34nDKxYcVDpm6JczWycbCi4zjAgMB
AAGjSDBGMCUGA1UdEQQeMByCCWxvY2FsaG9zdIIPbG9jYWxob3N0LnF6LmlvMB0G
A1UdDgQWBBT3Qs6/qQSmunLIGKQxz3GBO+RgIzANBgkqhkiG9w0BAQsFAAOCAQEA
lVI3sWr6wTtVtc7gsV9Kk99xNOUm5W2kp/Ot5CHvUIw68Ar1WIiouWT9BbjkvFc+
QpbtqKhluTdHI1/JP44r7A8qMApyYQLhw3AS/WTzRoOBOECJk3hYgGBIxAaoqvKY
HKCOULTqkoX8pgNhYobebn/BpeoSvXW+oxT21y7ElE01eMtrLsqXKaN5FODxVzJq
7jatxCaRZCy2Ki3R0cB5ZMIVvWSDeT1TLgh5UKWdldNsTdTNhbQSdm8ayU0uj4fH
tKqwh9lKvrBJiawghmADjZjeNEQzIJfjznF/soqVZnRNZO/phDH327lDE2UcD1IN
k4BqNRJmz5lrQeYz8GcfYA==
-----END CERTIFICATE-----

Inspired by the answer of #tresf and based largely on the blogpost How to Create Your Own SSL Certificate Authority for Local HTTPS Development by
Brad Touesnard, I created a set of commands using openssl.
# Generate the root key
openssl genrsa -des3 -out myCA.key 2048
# Generate a root-certificate based on the root-key
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.pem
# Generate a new private key
openssl genrsa -out example.com.key 2048
# Generate a Certificate Signing Request (CSR) based on that private key
openssl req -new -key example.com.key -out example.com.csr
# Create a configuration-file
echo \
"authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = example.com
"> example.com.conf
# Create the certificate for the webserver to serve
openssl x509 -req -in example.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial \
-out example.com.crt -days 1825 -sha256 -extfile example.com.conf
How to use these files
1. Let your CA be trusted by your browser/keychain
Add myCa.pem to your browser/keychain to trust certificates signed by your new root certificate
2. Sign requests with your certificate
Add example.com.crt and example.com.key to the configuration of your webserver to sign requests to your domain

To mimic the CA-chain requirements mandated by Firefox 54, the following is required:
Keypair marked as a Root-CA, capable of generating an SSL certificate.
Second keypair marked for SSL which obtains a chained certificate from Root-CA
To illustrate how this is done with Java keytool including the steps to create private keystores:
# Create a Root-CA private keystore capable of issuing SSL certificates
keytool -genkeypair -noprompt -alias my-ca -keyalg RSA -keysize 2048 -dname CN=localhost -validity 3650 -keystore .\my-ca.jks -storepass pass77 -keypass pass77 -ext ku:critical=cRLSign,keyCertSign -ext bc:critical=ca:true,pathlen:1
# Export the Root-CA certificate, to be used in the final SSL chain
keytool -exportcert -alias my-ca -keystore .\my-ca.jks -storepass pass77 -keypass pass77 -file .\my-ca.crt -rfc -ext ku:critical=cRLSign,keyCertSign -ext bc:critical=ca:true,pathlen:1
# Create a container SSL private keystore (external localhost.foo.bar dns entry optional:IE11 domain intranet policy)
keytool -genkeypair -noprompt -alias my-ssl -keyalg RSA -keysize 2048 -dname CN=localhost -validity 3650 -keystore .\my-ssl.jks -storepass pass77 -keypass pass77 -ext ku:critical=digitalSignature,keyEncipherment -ext eku=serverAuth,clientAuth -ext san=dns:localhost,dns:localhost.foo.bar -ext bc:critical=ca:false
# Create a certificate signing request (CSR) from our SSL private keystore
keytool -certreq -keyalg RSA -alias my-ssl -file .\my-ssl.csr -keystore .\my-ssl.jks -keypass pass77 -storepass pass77
# Issue an SSL certificate from the Root-CA private keystore in response to the request (external localhost.foo.bar dns entry optional)
keytool -keypass pass77 -storepass pass77 -validity 3650 -keystore .\my-ca.jks -gencert -alias my-ca -infile .\my-ssl.csr -ext ku:critical=digitalSignature,keyEncipherment -ext eku=serverAuth,clientAuth -ext san=dns:localhost,dns:localhost.foo.bar -ext bc:critical=ca:false -rfc -outfile .\my-ssl.crt
# Import Root-CA certificate into SSL private keystore
keytool -noprompt -import -trustcacerts -alias my-ca -file my-ca.crt -keystore my-ssl.jks -keypass pass77 -storepass pass77
# Import an SSL (chained) certificate into keystore
keytool -import -trustcacerts -alias my-ssl -file my-ssl.crt -keystore my-ssl.jks -keypass pass77 -storepass pass77 -noprompt
Once this is done, only the Root-CA certificate needs to be trusted by Firefox, and can be imported using the GUI or via AutoConfig script.
The SSL server must be restarted using the new SSL private keystore, which will contain the chain of trust to work via SSL.
Since my-ssl.jks contains the entire chain of trust my-ca.jks, my-ca.crt, my-ssl.crt and my-ssl.csr can all safely be deleted (assuming my-ca.crt has been imported properly)

As #tresf and #Zombaya have stated, Firefox requires two certificates:
An authority certificate
A development certificate
The authority certificate is used to sign the development certificate. The development certificate is bound to an HTTP port. The web server listens to that port for requests.
Windows Development Environment
Other answers explain what to do in Java and Unix environments. Here's what I do in my Windows development environment. This creates certificates trusted by Firefox, Chrome, and Internet Explorer:
Override DNS with an entry in C:\Windows\System32\drivers\etc\hosts file.
127.0.0.1 dev.brainstorm.com
Create the authority and development certificates and store them in the local machine certificate store using PowerShell. Substitute "Brainstorm" with your company name and DNS entry. Run PowerShell as an administrator.
# Create authority certificate.
# TextExtension adds the Server Authentication enhanced key usage and the CA basic contraint.
$authorityCert = New-SelfSignedCertificate `
-Subject "CN=Brainstorm CA,OU=IT,O=Brainstorm Certificate Authority,C=US" `
-KeyAlgorithm RSA `
-KeyLength 4096 `
-KeyUsage CertSign, CRLSign, DigitalSignature, KeyEncipherment, DataEncipherment `
-KeyExportPolicy Exportable `
-NotBefore (Get-Date) `
-NotAfter (Get-Date).AddYears(10) `
-HashAlgorithm SHA256 `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FriendlyName "Brainstorm CA" `
-TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.1", "2.5.29.19={critical}{text}ca=1")
# Create development certificate.
# Sign it with authority certificate.
# TextExtension adds the Server Authentication enhanced key usage.
$devCert = New-SelfSignedCertificate `
-Subject "CN=Brainstorm,OU=Application Development,O=Brainstorm,C=US" `
-DnsName dev.brainstorm.com `
-KeyAlgorithm RSA `
-KeyLength 4096 `
-KeyUsage DigitalSignature, KeyEncipherment, DataEncipherment `
-KeyExportPolicy Exportable `
-NotBefore (Get-Date) `
-NotAfter (Get-Date).AddYears(10) `
-HashAlgorithm SHA256 `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FriendlyName "Brainstorm" `
-TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.1") `
-Signer $authorityCert
# Export authority certificate to file.
$directory = "C:\Users\Erik\Documents\Temp\Certificates\"
if(!(test-path $directory))
{
New-Item -ItemType Directory -Force -Path $directory
}
$authorityCertPath = 'Cert:\LocalMachine\My\' + ($authorityCert.ThumbPrint)
$authorityCertFilename = $directory + "Authority.cer"
Export-Certificate -Cert $authorityCertPath -FilePath $authorityCertFilename
# Import authority certificate from file to Trusted Root store.
Import-Certificate -FilePath $authorityCertFilename -CertStoreLocation "Cert:\LocalMachine\Root"
# Delete authority certificate file.
Remove-Item -Path $authorityCertFilename
Grant developer permission to host a website and service at specific URLs and ports (via IIS Express). Use standard SSL port for website, use another port for service. Why? IIS Express cannot simultaneously host two applications on same port differentiated by host name. They must use different ports.
netsh http add urlacl url=https://dev.brainstorm.com:443/ user="Erik"
netsh http add urlacl url=https://dev.brainstorm.com:44300/ user="Erik"
If you need to remove developer permission to host website at URL:
netsh http delete urlacl url=https://dev.brainstorm.com:443/
netsh http delete urlacl url=https://dev.brainstorm.com:44300/
List the certificates in Local Computer store.
Get-ChildItem -path "Cert:\LocalMachine\My"
Copy the thumbprint of the development certificate (not the authority certificate).
List the certificates bound to HTTP ports. (IIS Express configures ports 44300 - 44399 with its own SSL certificate.)
netsh http show sslcert
Copy the Application ID (it's the same for all IIS Express ports 44300 - 44399). Replace the website and service ports already bound by IIS Express with our development certificate (the certhash is the thumbprint from above). You may need to run netsh first, then enter http command, then enter add sslcert... command.
netsh http add sslcert hostnameport=dev.brainstorm.com:443 certhash=FE035397A4C44AB591A1D9D4DC0B44074D0F95BA appid={214124cd-d05b-4309-9af9-9caa44b2b74a} certstore=my
netsh http add sslcert hostnameport=dev.brainstorm.com:44300 certhash=FE035397A4C44AB591A1D9D4DC0B44074D0F95BA appid={214124cd-d05b-4309-9af9-9caa44b2b74a} certstore=my
If you need to unbind certificates from HTTP ports:
netsh http delete sslcert hostnameport=dev.brainstorm.com:443
netsh http delete sslcert hostnameport=dev.brainstorm.com:44300
In Visual Studio, configure the service's launchSettings.json file (in Properties folder):
{
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "https://dev.brainstorm.com:44300/",
"sslPort": 44300
}
},
"profiles": {
"Default": {
"commandName": "IISExpress",
"use64Bit": true
}
}
}
In Visual Studio, configure the website's launchSettings.json file (in Properties folder):
{
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "https://dev.brainstorm.com/",
"sslPort": 443
}
},
"profiles": {
"Default": {
"commandName": "IISExpress",
"launchBrowser": true,
"use64Bit": true
}
}
}
Configure IIS Express (in hidden .vs/config folder):
<sites>
<site name="Website" id="1" serverAutoStart="true">
<application path="/">
<virtualDirectory path="/" physicalPath="%IIS_SITES_HOME%\WebSite" />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:443:dev.brainstorm.com" />
</bindings>
</site>
<site name="Service" id="2">
<application path="/">
<virtualDirectory path="/" physicalPath="%IIS_SITES_HOME%\IIS Service" />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:44300:dev.brainstorm.com" />
</bindings>
</site>
<siteDefaults>
<logFile logFormat="W3C" directory="%IIS_USER_HOME%\Logs" />
<traceFailedRequestsLogging directory="%IIS_USER_HOME%\TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" />
</siteDefaults>
<applicationDefaults applicationPool="Clr4IntegratedAppPool" />
<virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>
In Firefox, navigate to about:config and set the security.enterprise_roots.enabled parameter to true.

What you'll probably want to do is generate another self-signed certificate with the same subject, issuer, and public key as the one you're trying to trust. However, instead of end-entity extensions, you'll want to specify that it's a CA certificate with "basicConstraints:cA" and that it can issue certificates with "keyUsage:cRLSign,keyCertSign". It might also be a good idea to add a nameConstraints extension to restrict it to only apply to a certain set of domains. If you add that certificate to Firefox's trust DB, everything should work as before.

Related

Configuring Kafka SSL with Let's Encrypt

I'm trying to setup a Kafka cluster and add SSL to it, but I'm getting always the same error:
INFO [SocketServer brokerId=0] Failed authentication with /XXX.XXX.XXX.XXX (SSL handshake failed) (org.apache.kafka.common.network.Selector)
I read several stackoverflow posts about this problem but I cannot fix it.
I'm using Kafka 2.5.0 on Ubuntu 18.04 with OpenJDK 14 and I used Let's Encrypt to generate certificates for my domain name (that are working perfectly with nginx).
First I created a pkcs12 file with the following command:
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name kafka1 -CAfile chain.pem -caname root
...then I created the keystore (with the -ext option as described in kafka docs):
keytool -importkeystore -deststorepass 'STRONG_PASS' -destkeypass 'STRONG_PASS' -destkeystore keystore.jks -srckeystore keystore.p12 -srcstoretype PKCS12 -srcstorepass 'STRONG_PASS' -alias kafka1 -ext SAN=DNS:{FQDN}
...also I added the certificate to the truststore:
keytool -trustcacerts -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit -noprompt -importcert -file /etc/letsencrypt/live/YOURDOMAIN/chain.pem
At this point, I believe that I have all of the necessary steps to have the keystore and the truststore correctly configured.
My broker config is:
broker.id=0
listeners=SSL://mydomain.com:9092
ssl.keystore.location=/path/to/keystore.jks
ssl.keystore.password=password
ssl.key.password=password
ssl.truststore.location=/path/to/jdk/lib/security/cacerts
ssl.truststore.password=changeit
ssl.secure.random.implementation=SHA1PRNG
security.inter.broker.protocol=SSL
ssl.endpoint.identification.algorithm= # I tried with and without this and the problem persists
advertised.listeners=SSL://mydomain.com:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/path/to/kafka_data
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.num.partitions=3
offsets.topic.replication.factor=2
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
min.insync.replicas=2
default.replication.factor=2
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=IP1:2181,IP2:2181,IP3:2181
zookeeper.connection.timeout.ms=18000
group.initial.rebalance.delay.ms=3000
Then I run the broker and try to execute the following command to know if everything is working:
openssl s_client -debug -connect mydomain.com:9092 -tls1 | head -n 50
And the error is displayed:
INFO [SocketServer brokerId=0] Failed authentication with /XXX.XXX.XXX.XXX (SSL handshake failed) (org.apache.kafka.common.network.Selector)
My domain is not the same as my hostname in the machine, I don't know if it could be a problem. I only want to add security to the first broker and then repeat the same in the other two, but first have the first one working.
What is wrong with my config? Maybe the truststore? or the hostname and domain name?

CA based Tomcat client authentication

I have troubles setting up a mutual authentication scheme using Tomcat 7 in Centos 7.
The server authentication is working as expected, but I am stuck on the client authentication.
The server certificate and the clients certificates are issued by the same CA. My goal is to allow any client with a certificate issued by this CA.
So far, my server.xml looks like this for the concerned connector:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150"
scheme="https" secure="true" sslProtocol="TLSv1.2" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" SSLEnabled="true"
keystoreFile="/absolute/path/to/mykeystore.jks" keystorePass="P455W0RD" keyAlias="myalias"
clientAuth="true"
truststoreFile="/absolute/path/to/mykeystore.jks" truststorePass="P455W0RD"
/>
When the keystore contains the client certificate, the mutual authentication successes.
However, when the keystore contains only the CA, the mutual authentication fails.
I have generated my keystore with the commands below:
openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name myalias -CAfile ca.crt -caname root
keytool -importkeystore -deststorepass <pass> -destkeypass <pass> -destkeystore mykeystore.jks -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass <pass> -alias myalias
keytool -importcert -alias root -keystore mykeystore.jks -storepass <pass> -file ca.crt
I also tried to remove the truststoreFile and truststorePass parameters from the connector, and add the CA to the cacerts in $JAVA_HOME/jre/lib/security/, but the mutual authentication still fails.
Could you please indicate me how to set up such a mutual authentication configuration?

import ssl certificate in Glassfish

i have the following issue:
I obtain a free certificate from comodo (90 days) for my glassfish web application and then i have imported the certs into glassfish 3.1 by following http://javadude.wordpress.com/2010/04/06/getting-started-with-glassfish-v3-and-ssl/
I have also modify the domain.xml file by replacing the alias s1as with my certificate alias and the file keystore.jks with the server.keystore....but when i try to access my web application with https protocol i got the following log error:
[#|2012-10-12T14:41:18.828+0200|WARNING|glassfish3.1.2|com.sun.grizzly.config.Gr
izzlyServiceListener|_ThreadID=25;_ThreadName=http-thread-pool-443(1);|GRIZZLY00
07: SSL support could not be configured!
java.io.IOException: SSL configuration is invalid due to No available certificat
e or key corresponds to the SSL cipher suites which are enabled.
Please help me..i know that here i can find the solution to my issue...
Unfortunately I don`t have enough reputation to post images of glassfish console admin, but let me try to help somebody just using text.
NOTE1: The configuration was done on Ubuntu 12.04 server and glassfish 3.1.2
Comodo gives you 4 files
your_domain.key (your private key)
your_domain.crt (your public key)
PositiveSSLCA2.crt (CA public key)
AddTrustExternalCARoot.crt (CA public key)
Import every public key into the file cacerts.jks. To do that merge the public key files in one file:
NOTE2: The order of the files DOES matter.
cat your_domain.crt PositiveSSLCA2.crt AddTrustExternalCARoot.crt > all.crt
Now import them using keytool:
keytool -import -trustcacerts -alias tomcat -file all.crt -keystore cacerts.jks
Create a p12 file with your private key:
NOTE3: You can use the same password for every file to make things easier.
openssl pkcs12 -export -in all.crt -inkey your_domain.key -out your_domain.p12 - name your_alias -CAfile PositiveSSLCA2.crt -caname immed
NOTE4: Don`t forget you alias (your_alias), you will need to reference it in glassfish admin console later.
Now import the private key using keytool:
keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore keystore.jks -srckeystore your_domain.p12 -srcstoretype PKCS12 -srcstorepass changeit -alias your_alias
Now your keystore.jks (with your private keys) and your cacerts.jks (with you public key) are ready to me used. If you want to check if everything is ok run:
keytool -list -keystore keystore.jks
keytool -list -keystore cacerts.jks
Go to the glassfish admin console and find the session:
Configurations->server-config->HTTP Service->Http Listeners->http-listener-2
Go to the SSL tab and change the Certificate NickName to your_domain.
Restart Glassfish server.
Preconditions:
installed keytool and GlassFish 4.x (with default keystore password changeit)
your source keystore used to generate CSR
e.g. ~/mySourceKeystore.jks with password myPassword and private key with alias myAlias
your valid certificate (obtained from CA)
e.g. ~/myCertificate.crt with password myPassword and alias myAlias
certificate of CA (obtained from CA)
e.g. ~/AwesomeCA.crt
Here are all steps how to import SSL certificate into GlassFish:
Navigate to GLASSFISH-HOME/domains/domain1/config
Import your source keystore (with private key) into GlassFish keystore:
$ keytool -importkeystore -srckeystore ~/mySourceKeystore.jks -destkeystore keystore.jks`
Enter destination keystore password: changeit
Enter source keystore password: myPassword
Entry for alias server successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
Import certificate of CA into GlassFish keystore:
$ keytool -import -v -trustcacerts -alias AwesomeCA -file ~/AwesomeCA.crt -keystore keystore.jks
Enter keystore password: changeit
Certificate was added to keystore
[Storing keystore.jks]
Import obtained SSL certificate into GlassFish keystore:
$ keytool -import -v -trustcacerts -alias myAlias -file ~/myCertificate.crt -keystore keystore.jks
Enter keystore password: changeit
Enter key password for <myAlias>: myPassword
Certificate reply was installed in keystore
[Storing keystore.jks]
At this moment error java.security.UnrecoverableKeyException: Cannot recover key would occur during GlassFish startup because you have different keystore password and alias key password. To prevent this error you need to execute:
$ keytool -keypasswd -alias myAlias -new changeit -keystore keystore.jks
Enter keystore password: changeit
Enter key password for <myAlias>: myPassword
Change default alias (s1as) in GlassFish to your myAlias:
$ asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.cert-nickname=myAlias
(Optional) You can change default SSL port (8181) in GlassFish to well known 443:
$ asadmin set server.network-config.network-listeners.network-listener.http-listener-2.port=443
Restart GlassFish
For Glassfish 4.x you can follow this Comodo Guide
Here is the web archive if link expires.

Enable SSL authentication between Apache Ace and Management agent

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.

Configure SSL on Jetty

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.