Java keystore (.jks) / jetty support?

[dessalines]

Does let's encrypt have any support for java web servers? If it's just apache and nginx, that'd be pretty limited.

[dessalines]

I went through the process of generating the cert:
./letsencrypt-auto certonly --standalone --email ...

Okay so it generated a file at:
/etc/letsencrypt/live/my_domain/fullchain.pem

And I used the following commands, which seemed to add it to a java keystore:

sudo openssl x509 -in /etc/letsencrypt/live/my_domain/fullchain.pem -inform PEM -out cert.der -outform DER
keytool -import -keystore keystore.jks -storepass "foobar" -file cert.der

I'll report back if I can get this working with my java web server.

[dessalines]

I could not get it working for now. My webserver seemed to load up fine, but my domain was unreachable. Here are the only log messages I could get from my jetty web server:

19:31:26.762 [Thread-1] DEBUG o.e.j.u.component.AbstractLifeCycle - starting SslConnectionFactory@56b11441{SSL->HTTP/1.1}
19:31:26.762 [Thread-1] DEBUG o.e.j.u.component.AbstractLifeCycle - starting SslContextFactory@a838b83(file:///home/as/df/keystore.jks,null)
19:31:26.879 [Thread-1] DEBUG o.e.jetty.util.ssl.SslContextFactory - Certificate SAN alias=mykey cn=my_domain in SslContextFactory@a838b83(file:///home/as/df/keystore.j
ks,null)
19:31:26.880 [Thread-1] INFO  o.e.jetty.util.ssl.SslContextFactory - x509={my_domain=mykey} wild={} alias=null for SslContextFactory@a838b83(file:///home/as/df/keystore
.jks,null)
19:31:27.071 [Thread-1] DEBUG o.e.jetty.util.ssl.SslContextFactory - managers=[sun.security.ssl.SunX509KeyManagerImpl@220c0f49] for SslContextFactory@a838b83(file:///home/as/df/keystore.jks,null)

[ajspera]

I was having the same problem as you on a dropwizard application but found a conversion method that seems to work at https://community.letsencrypt.org/t/how-to-use-the-certificate-for-tomcat/3677/2

Edit: This one has ios verification issues, see below for better solution.

[ajspera]

@tchoulihan Ended up having an issue with ios verification with that first solution I found. I cleaned it up to just use the fullchain and the following is responding and verifying on everything with Jetty.

openssl pkcs12 -export -out keystore.p12 -inkey privkey.pem -in fullchain.pem
keytool -importkeystore -destkeystore MyDSKeyStore.jks -srcstoretype PKCS12 -srckeystore keystore.p12

[dessalines]

I just tried both these, and neither worked :( . It does generate the file keystore.jks file correctly, and my server gave me no errors, but my domain still says unavailable.

Thanks for your help, I'll see if this is an issue with my framework(which uses jetty, but I should still inquire)

[dessalines]

Nevermind everybody, it turns out the issue was my server. I forgot to run it at port 443, and that's why it was unavailable.

I'll still leave this open, because letsencrypt should have a jetty guide, and this will be helpful.

Thanks @ajspera .

[dtrunk90]

Native Tomcat (7) support would be nice!

[schoen]

I'm going to say that #5212 is actually a duplicate of this.

Also, we never really resolved the question of how we want to handle requests for additional key/certificate representations (which has come up again and again).

@jsha, I seem to remember you suggested that most users might be better off with a mature reverse proxy in front of their web applications, but clearly not everyone is very satisfied with that approach. Do you have any ideas about how best to handle this?

Would it be sufficient to have some official documentation about how to make a JKS and an official deploy-hook sample script somewhere within that documentation? Or even somewhere in /etc/letsencrypt, like /etc/letsencrypt/examples or something?

[rasos]

This is an approach that creates a certificate keystore_le in pks format (source: http://blog.dgunia.de/2016/03/09/using-a-free-ssl-certificate-from-lets-encrypt-with-jetty/ )

openssl pkcs12 -export -in /etc/letsencrypt/live/yourdomain.com/fullchain.pem -inkey /etc/letsencrypt/live/yourdomain.com/privkey.pem -out fullchain_and_key.p12 -name jetty

keytool -importkeystore -destkeystore keystore_le -srckeystore fullchain_and_key.p12 -alias jetty

keytool -import -destkeystore keystore_le -file /etc/letsencrypt/live/yourdomain.com/chain.pem -alias root

[adferrand]

I come from the Java world, where I did setup a lot of servlet applications running in servlet containers like Jetty, Tomcat, GlassFish or Wildfly.

I would say, like @jsha, that the situation is pretty the same than with other HTTP dynamic content delivery servers in other languages (python, nodejs, php...): on production, the SSL termination must occur at a HTTPs reverse proxy server, placed in front of your dynamic server.

So from a production point of view, the effort would be better invested to make certbot support more of theses HTTPs reverse proxy servers. So Apache and Nginx are covered. Other well known appliances would worth it, like Squid, HAProxy or Traefik.

[Polve]

Yes, for HTTP it's easier to install the certificate for a reverse proxy like nginx or apache.

But still a native java version would be very useful for other applications like OpenFire (a Java Jabber server)

[adferrand]

Yes, but adding an official support to a new HTTP server is a big commitment for the certbot development team. Once it is done, it is expected that certbot would integrate in its workflow process to follow any evolution on the given http server, maintain the specific code, ensure retro-compatibility with proper integration tests and so on.

We can see from the various examples here, that the required operations can be done in a two or three calls to external libraries, and that fits very well as a bash authenticator plug-in hook with the manual plug-in of Certbot.

So like @schoen said, maintaining a good documentation, maybe with providing a collection of well designed manual authenticator hooks for various needs, would be the way to go that would respect the user requirement needs with a sustainable maintainance charge.

[Polve]

BTW I'm totally unable to use LE to generate a valid certificate for openfire, and I was unable to find any guide around.

I would appreciate very much if someone in this thread could help me on that subject.

[jsha]

@Polve I'm afraid that's off-topic for this thread. Please post to https://community.letsencrypt.org/ instead. Thanks!

[Polve]

I found that and the solution too, thanks and sorry. Feel free to delete this and the previous message to clean up the thread, thanks.

[ghost]

@adferrand I would like to help. Wildcard SSL certificates are a lot too much expensive in my humble opinion and I would prefer a more straightforward solution at least for Jetty. I know how to use OpenSSL to convert the necessary files into PKCS12 and keytool to convert it into JKS. Some work was done in Jetty: jetty/jetty.project#918
What could be improved in Certbot? Do you have an example of plugin that would help me to evaluate the effort to do to support Jetty?

[adferrand]

Hello @gouessej, I invite you to continue the discussion on the Let'sEncrypt support forum. There we can see the possible solutions to have a Jetty instance covered with Let'sEncrypt certificates.

[stale]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[stale]

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.