I need to get a wildcard cert for a website and I see some pretty big variations in pricing. Digicert is nearly $600 for a single year. RapidSSL says they offer one for a mere $249. Comodo has them for $450/yr. So far the only difference I've managed to locate was suggested at the stack forums which suggests that the certificate authority is different.
Can anyone help elucidate the differences between these certs? Is there really any good reason to buy the more expensive cert?
Are self-signed certs not an option?
What about LetsEncrypt? I dunno they do wildcards, but if you automate the process you can have any number of (sub)domains on the same cert.
Last time I checked, self-signed certs don't work for the public. Every visitor has to explicitly and manually create an exception for it. Am I missing something? Is there some way my self-signed certs can show up for any public visitor as safe in all of the various browsers?
dalecosp
I've looked into LetsEncrypt just a tiny bit and was put off by the fact that the certs are short lived (90 days) and also because you have to run their funky script with root permissions for it to auto-generate and auto-install a new cert every 90 days. Call me paranoid, but it seems insecure to grant root permissions to a script that I don't fully understand so it can contact a remote website (possibly falling victim to MITM or exploit on the other end).
New development: Some suggested using Namecheap where you can get a Comodo-signed, domain-validated cert for as little as $78.88 annually: https://www.namecheap.com/security/ssl-certificates.aspx
sneakyimp wrote:I've looked into LetsEncrypt just a tiny bit and was put off by the fact that the certs are short lived (90 days) and also because you have to run their funky script with root permissions for it to auto-generate and auto-install a new cert every 90 days. Call me paranoid, but it seems insecure to grant root permissions to a script that I don't fully understand so it can contact a remote website (possibly falling victim to MITM or exploit on the other end).
I think it is a choice between both: if you use the fully automated scripts that require root access, the fact that the certs are short-lived is no big deal, but then you worry about the security of the script and associated process. If you do the renewal manually, then you are in control and there's no worry about that aspect of security, but the short lifetime of the certs become a burden.
As I do like the fact that they are free, I went for a compromise solution since I am using DigitalOcean, a DNS provider that provides the relevant API integration: every two months plus I run acme.sh -- as a local script without root access -- to do an "automated" (more like manually initiated with a single command) DNS-based validation to issue/renew the certs but not automatically install them, i.e., the script initiates the DNS-based validation for Let's Encrypt, then uses my DigitalOcean key with DigitalOcean's API to update the required DNS records, and then I get the private key and certs that I manually install. (I literally manually install them, but then I could have written say, a Fabric command to "automate" the process, and hence effectively only run two commands each time.)
NogDog You can always use a self-signed cert and any user has the option of choosing advanced options and creating an exception for the cert. If browsers were simply to accept self-signed certs without complaint by default, then I could create my own self-signed cert for any website on earth. It should be evident that this would be bad. Most encryption schemes/protocols rely on a Web of Trust concept to assess data security. It's important to realize that this WoT concept is an attempt to ease the use of cryptography. It would be onerous and tedious to inspect the certificate of any site you visit every single time you want to check your email or social media.
laserlight Thanks for the detail on your process. You rightly point out the tradeoffs.
I'd be happy to pay $80/yr for a cert from NameCheap if I could be sure it is accepted by the all modern browsers. This is certainly an acceptable cost to me if I can avoid:
a) having to install a cert manually every 3 months. I'd surely forget this all the time and it would likely become impractical once you have a few servers. At the very least, I'd sooner be spending time retooling my software dev skills.
b) introducing some insecure script or process in a critical security function. Your process involving acme.sh+API is certainly interesting, but it's a 6,240-line script that (I presume) contacts remote servers via HTTPS to acquire a signed cert and then (I presume) contacts DigitalOcean via HTTPS to trigger API operations that perform root-level operations on your servers. I hope you'll forgive me if I say that it seems a bit Rube Goldbergian to me. Lots of moving parts and vectors for attack.
That said, LetsEncrypt starts to look a lot more appealing when certifications cost $600 per year.
I'm not really clear on your use of the phrase "DNS-based validation." I guess you are referring to the fact that these processes rely on the integrity of DNS to route their requests to the correct machine? E.g., when you contact https://acme-v01.api.letsencrypt.org/directory to generate a new cert, your script relies on DNS to connect it to the correct machine. Could you clarify what DNS records are getting updated?
Hmm. /usr/local/bin/certbot is 13 lines of Python. My sh script, "renew_certificates" is 109 lines of /bin/sh code and heavy on comments. When I saw that letsencrypt.org was sponsored by a large group of organizations including FaceBook, Akamai, Cisco, Mozilla Foundation, Chrome (Google), Ford Foundation, IdenTrust (which is an organization of more than 60 of the largest banks in the world), I decided I had about as much to risk as I do from being on the 'Net at all, since that pretty much represents most of the ownership of said 'Net ...
I guess what I mean, if I can't trust an organization like that, why would I trust GoDaddy, NetSol, Comodo, etc., etc.?
I have to assume that "DNS-based validation" refers simply to the fact that these certs are "Domain Validated" instead of "Organizational Validated" or "Extended Validated" ... see https://serverguy.com/security/types-of-ssl-certificates/
dalecosp I do not mean to impugn the goals or integrity of LetsEncrypt. They are also endorsed by the EFF, whom I tend to trust. I wouldn't mind seeing your compact python file and shell script if you're willing to share. That sounds way more manageable than trying to digest 6200 lines of shell script.
Some questions that occurred to me:
What if hackers manage to impersonate any of the remote sites involved in this Rube Goldberg machine using some DNS attack?
what if Ubuntu or Windows or FreeBSD publishes some kind of software update that breaks the wget/curl/http functions' ability to validate the HTTPS connections so the whole script breaks? This might be my biggest concern. There are so many moving parts and they have to perform flawlessly every 3 months if you want to automate.
* what if someone sneaked code into the complicated script to steal my private key? or somehow compromised my cert in a way that can be exploited?
As for trusting GoDaddy/NetSol/Comodo, I don't think you have to trust them very far if you generate your CSR yourself. All you ever send them is your CSR and your money. They send you back a signed certificate. The exposure is considerably less. I would also point out that, unless you take care to set up DNS CAA record, any other certificate authority on earth might issue a cert for your domain to some attacker if that attacker can satisfy their validation requirements. I believe bad certs have been issued before.
/usr/local/bin/certbot is their software. As I don't see a license in the file 
I'll post it:
#!/usr/local/bin/python2.7
# EASY-INSTALL-ENTRY-SCRIPT: 'certbot==0.12.0','console_scripts','certbot'
__requires__ = 'certbot==0.12.0'
import re
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('certbot==0.12.0', 'console_scripts', 'certbot')()
)Here's the simpler shell script ... this one services 3 domains, all on the same server that this script resides on. I have another more complex one that manages more domains on multiple servers.
#!/bin/sh
#############################################
# Auto-renew 'Let`s Encrypt' Certificates #
# for Foo/Bar/Baz #
#############################################
### THIS RAN ***PERFECTLY*** on 2/12/2018!!! JUST AS SHOWN BELOW...
#Sudo program
SUDO="/usr/local/bin/sudo"
#mount paths, user identifiers, etc. etc.
Foo_DOCROOT="/home/cc_admin/Foo/html"
Bar_DOCROOT="/home/cc_admin/Bar/html"
Baz_DOCROOT="/home/cc_admin/Baz/html"
#domains
Foo="thefoo.com,www.thefoo.com"
Bar="thebar.com,www.thebar.com"
Baz="thebaz.com,www.thebaz.com"
#turn off/on Apache Server if needed
STOP_APACHE="/usr/local/sbin/apachectl stop"
START_APACHE="/usr/local/sbin/apachectl start"
RESTART_APACHE="/usr/local/sbin/apachectl graceful"
#cerbot commands
CERTBOT="/usr/local/bin/certbot renew"
CERTBOT_DEBUG="/usr/local/bin/certbot certonly --dry-run"
CERTBOT_NEW="/usr/local/bin/certbot certonly --expand --webroot -w $Foo_DOCROOT -d $Foo -w $Baz_DOCROOT -d $Baz -w $Bar_DOCROOT -d $Bar"
OPTIONS="-o allow_other -o idmap=user -o uid=1002 -o gid=0"
#script (action) starts here
#Run the Certbot in "renew" mode. Omit "--dry-run" for production/cron
$SUDO $CERTBOT_NEW
#restart the Apache Server
$SUDO $RESTART_APACHEdalecosp Nope, Let's Encrypt only does "Domain Validation" certs for now. Rather, this refers to the validation mechanism, i.e., whether the proof of control over the domain name is provided through demonstrating control over the DNS (hence "DNS-based validation"), or through demonstrating control over the webserver that serves the website at the domain, etc.
sneakyimp wrote:a) having to install a cert manually every 3 months. I'd surely forget this all the time and it would likely become impractical once you have a few servers.
You could just as easily forget to renew a one year cert, i.e., in practice you depend on reminders like email from your host, and so there may be other ways to remind yourself. It is not impractical since it is basically just a two-step process, should you choose to write a script for the second step.
sneakyimp wrote:b) introducing some insecure script or process in a critical security function. Your process involving acme.sh+API is certainly interesting, but it's a 6,240-line script that (I presume) contacts remote servers via HTTPS to acquire a signed cert and then (I presume) contacts DigitalOcean via HTTPS to trigger API operations that perform root-level operations on your servers. I hope you'll forgive me if I say that it seems a bit Rube Goldbergian to me. Lots of moving parts and vectors for attack.
The script is long because it is a shell script... which on one hand I can understand why (no additional dependencies required), but on the other hand makes it far more verbose than it needs to be, besides the fact that the aim was to try and support a whole lot of different stuff that Let's Encrypt allows, along with various API integrations (which actually makes it far more than 6200+ lines: additional API integration code is in a different folder).
However, no root-level operations are triggered on any server. Rather, something that is both potentially worse and yet easier to manage happens: a DNS entry is created and then removed when done. It is worse because you're handing over the "keys to the kingdom" at a higher level than root access, yet it is easier to manage since you could use an unimportant account to hand over the API key for the DNS changes, and then from your various real accounts create a CNAME that you never need to change, thereby only requiring one API key and ensuring that any surreptitious DNS changes and whatever else are harmless... other than the problem of not actually getting your cert, but since that part is initiated manually you'll know if it happens.
In general though, I think that related to the "Reflections on Trusting Trust" thing, at some point you have to decide where to stop, whether it be using certbot, writing your own script entirely, writing your own Python interpreter, designing and implementing your own OS, designing and building your own computer, etc.