SoylentNews is people
SoylentNews
Arstechnica reports
In July of 2017, the nonprofit certificate authority Let's Encrypt promised to deliver something that would put secure websites and Web applications within reach of any Internet user: free "wildcard" certificates to enable secure HTTP connections for entire domains. Today, Let's Encrypt took that promised service live, in addition to a new version of the Automated Certificate Management Environment (ACME) protocol, an interface that can be used by a variety of client software packages to automate verification of certificate requests.
[....]Many hosting providers already support the registration of Let's Encrypt certificates to varying degrees. But Let's Encrypt's free certificate offering hasn't been snapped up by some larger hosting providers—such as GoDaddy—who also sell SSL certificates to their customers.
(Score: 4, Insightful) by The Mighty Buzzard on Wednesday March 14 2018, @02:30PM (56 children)
No, we won't be getting one for *.soylentnews.org. It's easier to have each VM take care of its own specific hosts than to automate the distribution of the cert and the restarting/HUP-ing of the relevant processes across multiple systems. Less admin butt-pain is of more concern to us than a smaller db for the folks at LE.
My rights don't end where your fear begins.
(Score: 1, Offtopic) by MichaelDavidCrawford on Wednesday March 14 2018, @03:04PM (4 children)
My life is now without meaning
My mind is a void
My heart but a distant echo of the passion that once burned within
Yes I Have No Bananas. [gofundme.com]
(Score: 3, Informative) by c0lo on Wednesday March 14 2018, @05:20PM (2 children)
Try some vitamin B complex. B12 and, to a lesser degree, B6 have neuroprotective effects [sciencedirect.com] (and low levels have neurodegenerative effects).
Can take it in excess as it doesn't bio-accumulate, you'll pee what is not needed - in addition to neuroprotection, a nice deep yellow pee might brighten your life (grin)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @08:53AM (1 child)
Bro, you gotta slam 50 grams waxy maize plus 20 grams BCAA within 7 seconds of finishing your last set of squat rack curls, otherwise you'll go straight catabolic.
(Score: 2) by c0lo on Thursday March 15 2018, @11:48AM
Fatsos can actually benefit from going catabolic.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @07:36AM
https://soylentnews.org/article.pl?sid=18/02/18/0244214 [soylentnews.org]
https://www.theguardian.com/science/2017/oct/13/magic-mushrooms-reboot-brain-in-depressed-people-study [theguardian.com]
https://www.telegraph.co.uk/news/science/science-news/11857821/Fish-diet-could-help-to-keep-depression-at-bay.html [telegraph.co.uk]
(Score: 0, Troll) by Anonymous Coward on Wednesday March 14 2018, @03:13PM (42 children)
Same for my systems. If they would do away with their "90 day only" stupidity it would actually be usable and provide a much-needed alternative in the CA industry. Until then it's just more stupid from morons that are a danger to the internet.
No, there aren't really alternatives when your two choices are a free certificate that requires stupid amounts of admin time to manage, or a cert from a "normal" provider that is charging anywhere from two to four orders of magnitude more than is reasonable. $1 a year for a DV multi-SAN cert is reasonable, anything more is not. $50 for three years is reasonable for an EV cert, anything more is not.
Perhaps in another 30 years we will have the automation required to make LE work as they want it to. Until then it's a good example of what happens when you let ignorant fucktards develop and run something that is the only alternative to multinational corporations colluding to keep the prices of their products unreasonably high.
(Score: 4, Informative) by TheRaven on Wednesday March 14 2018, @03:21PM (14 children)
Why is this a problem? I have acme-client in a weekly cron job, so my certs are renewed (re-signed) each week. The 90-day limit is ample even if that cron job fails for a few weeks. 90 days seems like a good compromise: It's short enough that you have to automate, sort enough that your revocation lists don't have to be very long, and long enough that you automated refresh isn't very urgent.
sudo mod me up
(Score: 2) by Whoever on Wednesday March 14 2018, @03:28PM (3 children)
Weekly?
It isn't too difficult to write a script that looks at the expiry date and renews the certs when they are about to expire. Alternatively, monthly is fine.
(Score: 2) by lentilla on Wednesday March 14 2018, @04:44PM
It's not that it's too difficult to write a script, it's just that it's so very easy to get wrong.
With cronjobs (and their ilk) there are so many failure modes to consider, and each further test you incorporate needs to be validated in its own right and adds another potential point of failure. Having an automated process isn't like having a personal assistant who'll pipe and and say "hey, boss, I couldn't renew our certificate this week" and has enough smarts to call you on the telephone if you don't reply to an email.
Like you said, it's not difficult, but writing cronjobs is an exercise in abundant caution.
(Score: 5, Informative) by bryan on Wednesday March 14 2018, @05:03PM
The ACME client itself will take care of this. You simply run the certbot command in a cron job as often as you want and it only renews certs that are close to the expiration date. Example output:
(Score: 2) by TheRaven on Thursday March 15 2018, @08:37AM
By default, acme-client will only renew certs that are within 30 days of expiring, so a weekly cron job means that it will typically have 3 attempts to renew that can fail before you actually suffer from problems. I realised that I'd left -F in my acme-client.sh from debugging, so mine was actually renewing the certs every week. I was still well below the threshold for rate limiting by Let's Encrypt, so there isn't really a down side of doing this.
Without the -F, there isn't really a reason not to run the cron job nightly - it will skip certs that are still a long way from expiring and you then have 30 attempts for the cron job to fail before your users notice anything.
sudo mod me up
(Score: 2) by zocalo on Wednesday March 14 2018, @04:47PM (9 children)
Note that we're just talking a bunch of standard certs here - we obviously don't need EV etc. on a closed network, just for things to work - so cost of the certificates isn't really an issue so much as the time and cost of deployment and management given the available resources and skillsets.
UNIX? They're not even circumcised! Savages!
(Score: 2) by NotSanguine on Wednesday March 14 2018, @09:15PM (6 children)
If it's not exposed to the internet, just use self-signed certs. That's not the use case that Let's Encrypt tries to address.
Let's Encrypt's advantage is that is that browsers and other *clients* on the internet will trust Let's Encrypt certs.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 4, Informative) by zocalo on Wednesday March 14 2018, @09:58PM (5 children)
Again, it's not the cost, it's the effort required to effect the change and manage the process. The least effort comes from certificates that are already trusted by the clients (e.g. from a well known CA - typically someone like Thawte), have a multi-year lifespan, and require as little in the way of additional PKI infrastructure, custom scripts, or manual processes as possible.
UNIX? They're not even circumcised! Savages!
(Score: 2) by NotSanguine on Wednesday March 14 2018, @10:36PM
Absolutely.
I was focusing my reply (and incorrectly in your case -- my apologies) on the use case where *all* clients and servers were members of the same organization. In that use case, everyone (including the various client applications) should already trust the internal CA certificate.
Once you bring in users whose devices/applications that are not owned/managed by the same organization, that goes right out the window.
For your use case, a widely trusted cert is likely not a bad idea.
However, if resources on the servers are sensitive, encryption isn't the only concern even if external parties are involved. If you need to do client *authentication* as well as encryption, Let's Encrypt would be much inferior to an internal CA and self-signed server *and* client certs, despite the issues around distribution and maintenance of the client certs.
There are ways around such a management issue of course (VNC/RDP access from internal hosts, etc.).
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @07:40AM
(Score: 2) by TheRaven on Thursday March 15 2018, @08:39AM (2 children)
Option 1: The network is only used by a fixed set of clients, so you can push out your signing cert to all of them easily.
Option 2: The network is used by clients that move from other networks to it. In this case, the air gap doesn't really buy you any security, because malware can infect one of the clients from the public network and can spread to your private network. In this case, you may as well set up a DMZ to push Let's Encrypt certs into the network.
sudo mod me up
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @09:04AM
For your regular malware, you are right. However, there are other ways to prevent those (updates, not running as admin).
A directed attack, on the other hand, is a lot easier if you have two way communication, and can attack one layer at a time, rather than needing to prepare everything ahead of time to sneak your attack in. It can be done - Stuxnet is an example - but your regular ADHD teen out to do some random damage is not going to take the time to find out the exact structure of the layers of security before even starting to write their attack code.
(Score: 2) by zocalo on Thursday March 15 2018, @11:11AM
Yes, a lot of the clients are fairly easy to push a new CA to, others just need a current cert and don't actually validate the entire trust chain so they're easy too (and could be selfsigned), the real PITAs are the propriatary tools that are at least partly managed by the vendor and don't tend to make the process easy *and* make people in management very twitchy because you're proposing a change to something they don't really understand but know that it's very expensive and very mission critical. Again, it's all about the paperwork and potential risk, not the cost, effort, or level of expertise, involved. The easiest and least frequent hoop to jump through is to standardise on a set of commercial certs from a widely recognised vendor that will work across every client and server and only require updating as infrequently as possible.
UNIX? They're not even circumcised! Savages!
(Score: 2) by NotSanguine on Wednesday March 14 2018, @11:14PM (1 child)
That's not necessarily true. Certificate auto-deployment is widely used in a variety of use cases, with client and server certs issued by an internal CA.
There are also a variety of mechanisms to automate certificate renewal, depending on the management platform in use.
This is especially important on secure wired and wireless networks which use 802.1x certificate authentication for access to the network.
There's nothing especially complicated about it, as long as you have appropriate tools, and the CA and policies defined around certificate issuance/deployment/renewal are properly defined.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1, Informative) by Anonymous Coward on Thursday March 15 2018, @09:23AM
You are mixing up his reasons.
Deploying official certificates (such as let's encrypt) needs to be manual, as the renewal requires an internet connection and the network is not connected to the internet. This makes the 90 day limit inconvenient.
Using an internal CA is inconvenient for different reasons.
Either way, buying an expensive three year certificate becomes the cheapest solution.
(Score: 3, Informative) by Thexalon on Wednesday March 14 2018, @03:22PM (13 children)
Really? Here's the approximate command log from my most recent LE certificate renewal:
me@mydevbox:~$ ssh myserver.example.com
me@myserver:~$ sudo /bin/certbot renew
And you're right, entering those 2 commands could be a pain in the butt if you have lots of servers to manage. In that case, you might set it up as a cron job and make it part of your standard webserver image, or write up a fairly simple script to do that across your farm. It only requires a stupid amount of admin time if you're a stupid admin.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2, Informative) by Anonymous Coward on Wednesday March 14 2018, @03:31PM (12 children)
Do the renewal on an IRC server on a shell where you don't have the ability to listen on port 443 or 80. Do the renewal on a managed network switch that is only accessible over a web interface. Do the renewal on a Cisco IOS router. Do the renewal on a Windows RDP service with only the RDP port forwarded.
Are you done being a jackass yet? Educate yourself before you spout bullshit. You've CLEARLY never managed network devices. Not everything is a Linux VPS connected directly to the internet.
(Score: 0, Touché) by Anonymous Coward on Wednesday March 14 2018, @04:09PM
It is possible to be right with also being an asshole, but I hope you feel better about yourself.
(Score: 5, Insightful) by insanumingenium on Wednesday March 14 2018, @04:31PM (6 children)
This is horses for courses, Let's Encrypt is for simple web servers to be validated by (most) browsers. If you are such a great admin, surely you can automate the DNS authentication method for your IRC server, which is the only case you mentioned where you might actually want to use the service. But the family run coffee shop on the corner needs the bare minimum of security without hiring a overpriced and whiny hack like you.
You are bitching about HTTPS certs for IOS routers and you think the other guy has clearly never managed network devices before, what a joke!
(Score: 2) by Booga1 on Wednesday March 14 2018, @07:17PM (5 children)
The certificate on the load balancers on our networks are used to present a single "host.company.com" front for our customers.
Nobody wants to see "NAMWEB619LB01.company.com" and "EURDBS821SW01.company.com" except the admins.
(Score: 2) by insanumingenium on Wednesday March 14 2018, @08:22PM (4 children)
Just in case you have never used it and/or don't know, Let's Encrypt isn't restricted to requesting certs for your local hostname, and the certs don't have to be requested from the machine where they will be used. These things make automation easier, and automation is an explicit goal of Let's Encrypt, but they are not prerequisites, you could run Let's Encrypt on any machine you like and put the cert on both LBs. Your LBs presumably provide TLS connections to the public, which isn't the case with an IOS router, LBs make sense to have public certs on. And if you want to buy certs commercially for whatever reason, that is OK too. The part I criticized was using Let's Encrypt for nonsense scenarios.
(Score: 2) by Booga1 on Wednesday March 14 2018, @10:19PM (3 children)
I responded with an example of network infrastructure where we use certificates. And of COURSE you don't have to request from the machines that eventually use the certs because the machines that use them may have no way of doing it, much less in an automated fashion. That was the main complaint after all. Not that it changes much for any other issuing certificate authority(even the one run by the company I work at). As for Cisco IOS, I've no direct experience with it(the stuff here is by F5). With a quick search it seems IOS does indeed support some use of certificates: Public Key Infrastructure Configuration Guide, Cisco IOS XE Release 3S [cisco.com]
A router that also performs load balancing seems to be a standard feature for them. Not sure if it's similar to the F5 stuff we use, but here's this:
(Score: 2) by insanumingenium on Wednesday March 14 2018, @11:17PM (2 children)
As for your Cisco link, the rest of that paragraph shows that it isn't talking about load balancing in the same sense as you are thinking.
(Score: 3, Interesting) by Booga1 on Wednesday March 14 2018, @11:51PM (1 child)
I think might see part of the disconnect. I'm not referring to managing the equipment by securing access to them via those certificates. I mean managing the certificates those devices have on them as they are used to masquarade/identify the machines behind them as the hosts specified in the certificates. Of course I can't imagine letting the public access the management of the devices. I'm not sure what scenario would someone want a publicly configurable privately owned network.
Also, the inter-network load balancing scenarios are indeed not what I was thinking of. Using certificates from LE would indeed be silly to use for strictly internal management of network equipment. I was thinking of server traffic load balancing, but I'm not sure if they offer a combo unit that does both routing and load balancing in that particular sense.
Anyway, I guess lack of specificity in the original complaint and how I interpreted the response is what got me started on this thread. Now that I see what you're referring to I'm pretty sure I'm in agreement with you.
(Score: 2) by insanumingenium on Thursday March 15 2018, @04:11PM
No worries mate, I probably could be clearer as well.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @04:32PM
Interesting, and yet I managed to renew the certificates on multiple machine that don't have access to the internet at all. Let's Encrypt does not depend on having a web server on the machine you want the certificate on. In fact, getting wildcard certs won't work with web-challenge-only clients anyway, you need a ACMEv2 compatible client and use the DNS challenge. The real problem with Let's Encrypt is that most people don't understand that it is a just a single provider that uses an open standard that has multiple clients and providers available.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @05:06PM
"Do the renewal on a managed network switch that is only accessible over a web interface."
nah...
"Do the renewal on a Cisco IOS router."
lmao
"Do the renewal on a Windows RDP service with only the RDP port forwarded."
#@%$ you!
(Score: 2) by NotSanguine on Thursday March 15 2018, @08:09AM
Those are all poor use cases for *any* external (free or otherwise) certificate.
An internal CA should be used for these types of use cases, not an external one.
As an aside, the CA in question calls itself "Let's Encrypt" as its goal is to increase the number of *internet* facing servers that can communicate via TLS.
The use cases you mention are both orthogonal and pretty much irrelevant to Let's Encrypt's mission. That you don't understand this speaks volumes about your knowledge of such things.
Setting up an internal CA is fairly simple, as long as you take a little time to learn what you're doing.
Here's a place to start [wikipedia.org]
There are a number of Open Source PKI implementations that you can use for this purpose:
https://en.wikipedia.org/wiki/OpenXPKI [wikipedia.org]
https://en.wikipedia.org/wiki/OpenCA [wikipedia.org]
https://en.wikipedia.org/wiki/DogTag [wikipedia.org]
And even if you're using a proprietary [wikipedia.org] environment, it's available there too.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @10:08AM
There's several ways to automate each of those scenarios. Some of them depend on some extra pieces, but nothing onerous.
If they're not internet-accessible names, no public CA should be issuing certificates for them, so we're not concerned in the slightest about certificates for internal names. The devices themselves don't have to be internet accessible to have certificates generated, signed and deployed via some sort of NMS or central automation, or to reach out individually to verify via external DNS zone management APIs. In Cisco-land, you only want certs on edge devices (ASAs, Ironports, etc) or VPN endpoints and the like, baby ISRs and bigger can probably do it all themselves with EEM and TCL, but I've not really looked for options there, best to handle it in the management platform. Anything appliance-y is going to need central management.
A "managed" network switch with only a web interface and which doesn't offer an NMS-accessible API could be an issue. If someone didn't want to click past the certificate warning on that device, they should've considered buying a proper managed switch. I've yet to see anyone with a cheapo "websmart"-type switch even notice the issue or regard it as a problem.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @03:30PM (11 children)
Good thing you posted as AC, as you showed us how incompetent you are. I have 3 VPS and ~10 domains, all using LE, and they require no interaction to renew. It is going on autopilot since LE launch, and the only problem I had was when they once changed the ToS, that had to be updated in the requests.
Yeah, stupid amounts of time for stupid admins.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @03:35PM (10 children)
If morons could fly this place would be LAX. Not everything is a Linux VPS, dumbass. See the reply to the post above yours.
(Score: 1, Touché) by Anonymous Coward on Wednesday March 14 2018, @03:43PM (8 children)
Whichever system you're using, if you can't automate a simple cert renew, the dumbass clearly is you.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @04:08PM (7 children)
Says the dipshit that has never tried to automate something other than a simple HTTPd cert renewal. There simply is no way to automate renewals in some scenarios. Can't listen on port 80 or 443? Don't run your own public DNS servers? NO AUTOMATION FOR YOU!
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @04:19PM (1 child)
OMG I can't paint with this screwdriver! OMG I can't cook with this hammer! OMG this brush doesn't charge my cellphone!
Keep complaining about the tools you have, incompetent dumbass.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @04:36PM
Just a fair warning since you're clearly a dipshit: don't smoke around your strawman. Strawmen are flammable.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @04:31PM (2 children)
If you can do it on the command line, you can automate it. It may take some work, but it is possible.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @04:34PM (1 child)
And if you can't do it from the command line?
(Score: 1, Touché) by Anonymous Coward on Wednesday March 14 2018, @05:28PM
Then learn how to do it.
(Score: 2) by NotSanguine on Thursday March 15 2018, @08:16AM
As someone who has implemented/automated PKI in large enterprise environments as well as small environments, I agree with the other AC.
This stuff is pretty easy to automate. Which is why stuff like 802.1x [wikipedia.org] authentication with certificates is pretty widespread.
Sure there are edge cases which make things a little more complicated, but so what?
Let's Encrypt's value is *specifically* in the web server certificate environment. In fact, it was rolled out to encourage more websites to support TLS. And you're disparaging it because it does what it was intended to do? Please.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by NotSanguine on Thursday March 15 2018, @08:16AM
As someone who has implemented/automated PKI in large enterprise environments as well as small environments, I agree with the other AC.
This stuff is pretty easy to automate. Which is why stuff like 802.1x [wikipedia.org] authentication with certificates is pretty widespread.
Sure there are edge cases which make things a little more complicated, but so what?
Let's Encrypt's value is *specifically* in the web server certificate environment. In fact, it was rolled out to encourage more websites to support TLS. And you're disparaging it because it does what it was intended to do? Please.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: -1, Flamebait) by Anonymous Coward on Wednesday March 14 2018, @05:13PM
if it's not a linux vps then who cares about you? you are a common street hooker who whines about your ass warts.
(Score: 2) by bob_super on Wednesday March 14 2018, @06:41PM
You seem to have identified a wonderful opportunity, and untapped market, and have the highly-profitable solution to its needs.
Looking forward to seeing you become a millionaire or a billionaire soon. What's your company's name going to be ?
(Score: 2) by urza9814 on Wednesday March 14 2018, @04:49PM (3 children)
Seriously. I *really* could have used this about a year ago, but now I've invested quite a lot of time into building a system to work around the requirement to validate each individual subdomain.
I've got different certs on each VM, but all the VMs are behind one IP address...so some reverse proxy and NAT strangeness lets me twist that service just right so I can have one server generate all the certs (and that's all it does...no web server, no open ports) which then copies the validation files to my web servers. My domains all point to that one IP, and anything hitting port 80 gets redirected to that domain's web server VM which serves the validation files. Then the certs get generated and copied out to whatever server actually needs them. Which was a huge pain to set up, but now I'm not redoing that crap until one of these scripts breaks...
Of course, that was still easier to set up than the ONE domain that I actually manage the way LE expects you to. I've got one site hosted on Gandi.net, and there's a plugin for the official certbot which lets you generate certs for their infrastructure...but EVERY SINGLE TIME I generate that cert I have to reinstall and reconfigure that plugin first for some reason...
LE is a huge PITA to use...but it still beats spending a couple hundred bucks for a paid cert. And adding wildcard certs should make it far easier at least in terms of the issues I usually have in my (admittedly non-standard) use case...
(Score: 2) by richtopia on Wednesday March 14 2018, @05:47PM
My situation is similar as I self-host a number of services in my house, so one IP and reverse proxy to direct traffic. I never implemented HTTPS as my website is just static content, but I probably will setup a wildcard certificate now that they exist. I think it will be particularly nice for firing up new web services in a separate docker container for demonstration purposes that isn't intended for production.
(Score: 2) by bob_super on Wednesday March 14 2018, @06:45PM (1 child)
> LE is a huge PITA to use...but it still beats spending a couple hundred bucks for a paid cert.
How many hours of extra work qualify as "a huge PITA" ?
Just wondering about diminishing returns.
(Score: 2) by urza9814 on Wednesday March 14 2018, @07:12PM
(Score: 2) by vux984 on Wednesday March 14 2018, @06:00PM (3 children)
I don't think this is the target market. Here's an example where wildcards are pretty useful... one company i work with creates b2b portals, and gives the partner business friendly urls... like if we were example.com, then we might have portals at...
mcdonalds.b2b.example.com
wendys.b2b.example.com
dairyqueen.b2b.example.com
... etc...
all these are lightly used domains served from a single server.
every few weeks another company joins, occasionally others go dormant and are taken down.
a wildcard cert *.b2b.example.com on the server would eliminate a bunch of makework.
(Score: 2) by The Mighty Buzzard on Wednesday March 14 2018, @07:14PM (2 children)
We've got plenty of lightly used hosts but they're scattered across three different VMs depending on their function. Technically we could put them all on one VM but we prefer to keep all the stuff we're tinkering on and very well may break over on lithium(aka dev), all the external but non-primary services on beryllium, and all the internal staff services on boron. It just makes sense to us to do things that way and it's much easier to write a cron.daily script along the lines of "certbot renew && restart_some_services.sh" for each than to deal with writing one script to handle renewing, copying the cert to each box, and restarting the services on each box. We like small and simple over larger and more complicated.
My rights don't end where your fear begins.
(Score: 2) by vux984 on Wednesday March 14 2018, @08:00PM (1 child)
If you thought I was suggesting you change anything you are currently doing, you misunderstood me.
I was just giving an example, where one of the companies I work with really stands to benefit from wildcard certs.
Now I'm curious though, do you actually need to copy the cert to multiple boxes, or could each box just request its own wildcard cert?
(Score: 2) by The Mighty Buzzard on Wednesday March 14 2018, @09:16PM
Naw, just getting more specific about our own example for those following along.
Not sure on the wildcard cert policy. They may give out as many per base domain as they gave out of non-wildcard certs but I somehow doubt it. And unless/until we actually need a new hostname added, there's no benefit in switching to wildcard certs over multi-host certs since we already have the multi-host certs set up properly.
My rights don't end where your fear begins.