So what? That doesn't negate the point. You're arguing that X is pointless because Y might happen, where X and Y can be literally anything.
I'm just saying that short-lived certificates don't make things better by and off themselves.
Just go there and you have it:
https://gethttpsforfree.com/
The GUI is simple, but it does the job it is intended for and that's good enough IMHO.
You can create 1 certificate with all 40 domains on it. If they're all served on the same machine, the process is automated by the client. If the domains are on different machines you can use DNS verification or the manual verification method.
You only need to configure your servers once. Letsencrypt can auto-renew via a cronjob. If you configure configure services to use the /live/
versions of certificates you only need the services to restart (the /live/
files are just symlinks to versioned certificates).
If you are dealing with all those different systems, it would probably make the most sense to use an automated script to go onto each box and update certificates/restart services.
The point is that you can easily setup a machine once and have it auto-renew OR setup an automated tool once to deploy across your network. It's not a nightmare, this is just how the industry has progressed in the past 15 years. Or you can buy commercial certificates.
I know this page. last time I tried I just got errors, but may have been fixed by now...
also there's the main problem that each and every subdomain needs its own verification, which makes this REALLY annoying.
I don't see how. Renewal uses the same method that was used to create the cert, so it's a once-off thing.
He can create them all in one cert if he wants, even with the current limits (or even with last years limits). Create the cert, then next week "--expand" the cert with new domains using whatever verification method you desire. He can have all 40 or so in one certificate, using mixed verification methods, and renewal isn't constrained by the 20-per-week limit.
Each domain, once. And you can add 20 domains in a single command, utilising mixed verification methods. A cronjob does all the work from then on.
(This is all in the documentation I linked you to back in the 90-day thread, you should really read it!)
I was talking about the website thing thatâs why I quoted it.
the problem is that you have to push a different key for each and every subdomain, pretty much manual mode. if you wouldnt need to verify each subdmain it would be a lo easier.
Uh, yeah. If you could just get SSL certificates for any domain, whether you demonstrate control of it or not, it would be MUCH easier!
I think you are misinterpreting what I said. verifying each root domain is obvious enough but having to verify each and every subdomain is something thatâs just weird. usually when you validate the root you dont have to validate the subs that are attached to that root.
No, Iâm interpreting what youâre saying correctly. Itâs exactly the same complaint that youâve expressed in other threads.
Basically, you donât like the 90 day expiry, and everything is somehow about that. You havenât been able to come up with any valid reason why itâs bad, so youâre now saying the lack of wildcards is hugely inconvenient. Even though that has absolutely nothing to do with the topic of the thread (âShort expiry periodâ).
The wildcard threads have gone into detail about the reasons why itâs not currently available, however even that may change as the LE guys have indicated that theyâre looking into wildcards as a possible future update.
If you want an SSL cert for a FQDN then you need to demonstrate control of it, regardless of whether itâs domain.tld or sub1.domain.tld or sub2.sub1.domain.tld. This isnât hard.
And it has nothing to do with the âshort certificate periodâ - renewal is as simple as a single command âletsencrypt renewâ, no matter how many subdomains youâre renewing, no matter what verification you originally used, no matter how many verification methods were used.
Now please, enough with the handwaving and noise contributed to the forums.
well I dont even care that much about wild card certs rather than wild card validations, also while this isnt directly related to cert lifetime, that fact makes it more inconvenient that it already is, especially for people who have to validate manually
I have a need for SAN certs with wildcards. I have over 100 (currently 350+) subdomains and need support for wildcards in SAN (as SAN is limited to 100 entries).
Verification of *.example.com
would be a matter of creating a DSN TXT entry at the base domain level (example.com
), which would prove ownership of the domain and subdomains/hosta.
The multiple subdomains (subhosts really) all run on a single nginx server instance (i.e. server_name *.example.com
), so it would be impossible to install multiple certificates to handle this.
I Read that post, but is has been a long time since any mention or a solution. I read over the IETF document, and it ACME draft basically does cover wildcards, but it appears no one has implemented it. I also canât find any suggestions of workarounds (other than using Cloudflare as a front end proxy). I do have Cloudflare in front, but not all hosts are âproxiedâ, so a wildcard cert is needed. Right now I am in a bind as my StartSSL multi-domain multi-wildcard Cert, which was obtained before the WoSign âincidentâ) is now starting to fail on some browsers (specifically mobile chrome).