Installing a Let’s Encrypt SSL Certificate on MAMP Pro Aug 28, 2018 MAMP Pro is a popular tool to host a website on macOS, but it’s lacking in the SSL certificate department. Let's Encrypt is an upcoming certificate authority to be launched in mid-2015 that will provide free and automated Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates. If You Don’t Mind a Web Client on Mac, Try ProtonMail The aforementioned ProtonMail has a terrific iOS app, but no Mac software. You can, however, access your encrypted email through your web.
On the advantages side, I see several benefits to using the Let's Encrypt service (e.g., the service is free, easy to setup, and easy to maintain). I'm wondering what, if any, are the disadvantages to using Let's Encrypt? Any reasons why website operators -- whether big like Twitter or small like a local photographer -- should not consider replacing their existing SSL services with companies like GoDaddy with this service?
(If the service is not yet available, this disadvantage can be ignored -- I'm more wondering about disadvantages once it is available for general public use.)
5 Answers
Let's Encrypt is a Certificate Authority, and they have more or less the same privileges and power of any other existing (and larger) certificate authority in the market.
As of today, the main objective downside of using a Let's Encrypt certificate is compatibility. This is an issue that any new CA faces when approaching the market.
In order for a certificate to be trusted, it must be signed by a certificate that belongs to a trusted CA. In order to be trusted, a CA must have the signing certificate bundled in the browser/OS. A CA that enters the market today, assuming they are approved to the root certificate program of each browser/OS from day 0 (which is impossible), will be included in the current releases of the various browser/OS. However, they won't be able to be included in older (and already released) versions.
In other words, if a CA Foo joins the root program on Day 0 when the Google Chrome version is 48 and Max OSX is 10.7, the Foo CA will not be included (and trusted) in any version of Chrome prior to 48 or Mac OSX prior to 10.7. You can't retroactively trust a CA.
To limit the compatibility issue, Let's Encrypt got their root certificate cross-signed by another older CA (IdenTrust). This means a client that doesn't include LE root certificate can still fallback to IdenTrust and the certificate will be trusted... in an ideal world. In fact, it looks like there are various cases where this is not currently happening (Java, Windows XP, iTunes and other environments). Therefore, that's the major downside of using a Let's Encrypt certificate: a reduced compatibility compared to other older competitors.
Besides compatibility, other possible downsides are essentially related to the issuance policy of Let's Encrypt and their business decisions. Like any other service, they may not offer some features you need.
Mac Client For Skype For Business
Here's some notable differences of Let's Encrypt compared to other CAs (I also wrote an article about them):
LE doesn't currently issue wildcard certificates (they will begin issuing wildcard certificates on Jan 2018)LE is now issuing wildcard certificates using the updated ACMEv2 protocol- LE certificates have an expiration of 90 days
- LE only issues domain- or DNS-validated certificates (they don't plan to issue OV or EV, hence they only validate ownership and not the entity requesting the certificate)
- Current
very-restrictiverate limiting†(they will continue to relax the limit while getting closer to the end of the beta)
The points above are not necessarily downsides. However, they are business decisions that may not meet your specific requirements, and in that case they will represent downsides compared to other alternatives.
† the main rate limit is 20 certs per registered domain per week. However this does not restrict the number of renewals you can issue each week.
The reason to use Let's Encrypt can be the price. Those certificates will be for free.
But I see one possible disadvantage for nonsmall web sites. Big CA offer wildcard certificates, Extended Validation certificates which have some advantages (from my point of view). Moreover this program is directed to web servers, but what if you have some application server or you want to secure mail server
Update: Currently is possible to request certificate, not binded to web servers. So my last argument is not valid anymore. here is some example of using this option:
Update2: From January 2018 Let's Encrypt will begin issuing wildcard certificates
Wildcard Certificates Coming January 2018
Jul 6, 2017 • Josh Aas, ISRG Executive Director
Let’s Encrypt will begin issuing wildcard certificates in January of 2018. Wildcard certificates are a commonly requested feature and we understand that there are some use cases where they make HTTPS deployment easier. Our hope is that offering wildcards will help to accelerate the Web’s progress towards 100% HTTPS.
So one more argument is not valid anymore.
One disadvantage that makes big companies not consider Let's Encrypt is that visitors that connect to the site can't be sure that it is the actual company that hosts the site.
This is because Let's Encrypt issues certificates for a domain free of charge without identity validation (personal or corporate) (Let's Encrypt only offers domain validation).
Edited to add:For the purpose of secure transmission this is not a big problem. But, if you want to verify that it is the actual company you were looking for that holds the domain name a whois lookup may not be enough. Class 2 or 3 or EV certificates have the advantage that the company and domain are verified by the certificate authority.
One more issue with using Let'encrypt is that in enterprise scenario we need to install certificate to load balancer and CDN provider as well. Not all CDN providers have APIs to change this automatically. Also as of now Let's encrypt's validity is of 90 days which complicates this process more.
Yes, by using Let's Encrypt you revoke your right to defend your Intellectual Property including Patent, Trademark, Trade Secret or Copyright against infringement by ISRG.
BY WAY OF FURTHER EXPLANATION REGARDING THE SCOPE OF THE DISCLAIMER, AND WITHOUT WAIVING OR LIMITING THE FOREGOING IN ANY WAY, ISRG DOES NOT MAKE, AND ISRG EXPRESSLY DISCLAIMS, ANY WARRANTY REGARDING ITS RIGHT TO USE ANY TECHNOLOGY, INVENTION, TECHNICAL DESIGN, PROCESS, OR BUSINESS METHOD USED IN EITHER ISSUING LET’S ENCRYPT CERTIFICATES OR PROVIDING ANY OF ISRG’S SERVICES. YOU AFFIRMATIVELY AND EXPRESSLY WAIVE THE RIGHT TO HOLD ISRG RESPONSIBLE IN ANY WAY, OR SEEK INDEMNIFICATION AGAINST ISRG, FOR ANY INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS, INCLUDING PATENT, TRADEMARK, TRADE SECRET, OR COPYRIGHT.
That last sentence.
schroeder♦Encrypt Mac Files
Not the answer you're looking for? Browse other questions tagged tlscertificateswebservercertificate-authorityletsencrypt or ask your own question.
I am developing a Java application that queries a REST API on a remote server over HTTP. For security reasons this communication should be switched to HTTPS.
Now that Let's Encrypt started their public beta, I'd like to know if Java currently works (or is confirmed to be working in the future) with their certificates by default.
Let's Encrypt got their intermediate cross-signed by IdenTrust, which should be good news. However, I cannot find any of these two in the output of this command:
I know that trusted CAs can be added manually on each machine, but since my application should be free to download and executable without any further configuration, I am looking for solutions that work 'out of the box'. Do you have good news for me?
Hexaholic4 Answers
[Update 2016-06-08: According to https://bugs.openjdk.java.net/browse/JDK-8154757 the IdenTrust CA will be included in Oracle Java 8u101.]
[Update 2016-08-05: Java 8u101 has been released and does indeed include the IdenTrust CA: release notes]
Does Java support Let's Encrypt certificates?
Yes. The Let's Encrypt certificate is just a regular public key certificate. Java supports it (according to Let's Encrypt Certificate Compatibility, for Java 7 >= 7u111 and Java 8 >= 8u101).
Does Java trust Let's Encrypt certificates out of the box?
No / it depends on the JVM. The truststore of Oracle JDK/JRE up to 8u66 contains neither the Let's Encrypt CA specifically nor the IdenTrust CA that cross signed it. new URL('https://letsencrypt.org/').openConnection().connect(); for example results in javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException.
You can however provide your own validator / define a custom keystore that contains the required root CA or import the certificate into the JVM truststore.
https://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the-default-list-in-the-jdk-jre/134/10 discusses the topic as well.
Here is some example code that shows how to add a certificate to the default truststore at runtime. You'll just need to add the certificate (exported from firefox as .der and put in classpath)
Based on How can I get a list of trusted root certificates in Java? and http://developer.android.com/training/articles/security-ssl.html#UnknownCa
potameI know the OP asked for a solution without local configuration changes, but in case you want to add the trust chain to the keystore permanently:
source: https://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the-default-list-in-the-jdk-jre/134/13
Jan BerkelJan BerkelDetailed answer for those of us willing to make local config changes that includes backing up the config file:
1. Test if it is working before the changes
If you don't have a test program already, you can use my java SSLPing ping program which tests the TLS handshake (will work with any SSL/TLS port, not just HTTPS). I'll use the prebuilt SSLPing.jar, but reading the code and building it yourself is a quick and easy task:
Mac Encrypt A Folder
Since my Java version is earlier than 1.8.0_101 (not released at the time of this writing), a Let's Encrypt certificate will not verify by default. Let's see what failure looks like before applying the fix:
2. Import the certificate
I'm on Mac OS X with the JAVA_HOME environment variable set. Later commands will assume this variable is set for the java installation you are modifying:
Make a backup of the cacerts file we will be modifying so you can back out any change without reinstalling the JDK:
Download the signing certificate we need to import:
Perform the import:
3. Verify that it is working after the changes
Verify that Java is now happy connecting to the SSL port:
For JDK which do not support Let's Encrypt certificates yet, you can add those to the JDK cacerts following this process (thanks to this).
Download all the certificates on https://letsencrypt.org/certificates/ (choose the der format) and add them one by one with this kind of command (example for letsencryptauthorityx1.der):