Short certificate period - no useable on multi server scenario

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.

2 Likes

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.

1 Like

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.

Hi @tmorehouse,

Please see

1 Like

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).