justin_oaks

When a company makes it impossible to correct their stupidity, it's a malicious act. The behavior speaks loud and clear: "We don't care what damage we do to developers or users. And we don't want to hear about it."

That happened to me exactly once in my 20-year career. It was on a web server (maybe even NGINX) that had too many cached files.

Even though it only happened once, I still set up monitoring for inode exhaustion.

Yes, I see that AWS Route53 can limit credential scope. That kind of thing helps a lot.

I've never heard of that CNAME approach for changing the validation domain. That looks like a viable solution since it requires a one-time setup on the main domain and ongoing access to the second (validation) domain.

That looks like a great solution. I'll probably make use of that as soon as it's available.

Ah, that's a clever mechanism. That way the secondary machine could not only keep the token secure, but also validate which DNS records to create.

Oh... that's fantastic! It specifically addresses my concerns about needing DNS credentials accessible to scripts.

The article says it is for those who

> prefer to keep DNS updates and sensitive credentials out of their issuance path.

Some of this might have been "because I want to see if I can". Another reason is "It bothers me to keep seeing this browser tell me my connection is insecure".

As for putting it on a separate VLAN and securing traffic with firewall rules, that may be as much or more trouble than setting up the automated certificate renewal. At least with the automated certificates there may not be any further maintenance required. With firewall rules, you'll need to open up the firewall each time you want a new device to access the printer.

I read a lot about people running things like Caddy which will automatically retrieve Lets Encrypt certificates. And I think it makes sense for publicly accessible web sites since you can use an HTTP challenge with Let's Encrypt.

For internal-use certificates, you'll have to make use of a DNS challenge with Let's Encrypt. I've been hesitant to set that up because I'm concerned about the potential compromise of a token that has permissions to edit my DNS zone. I see that the author creates exactly that kind of token and has permanently accessible to his script. For a home lab where he's the only person accessing his hardware, that's less of a concern. But what about at a company where multiple people may have access to a system?

Am I being too paranoid here? Or is there a better way to allow DNS challenges without a token that allows too much power in editing a DNS zone?

I agree that it's not a serious project, but I wouldn't call it a joke. Jokes are funny.

Without TLS, sometimes still referred to as SSL, a webite's content can be modified by anyone controlling the network path. This includes ISPs and WiFi operators.

Sure, your website may have unimportant stuff on it that nobody relies on, but do you want visitors to see ads in your content that you didn't put there?

This has been my experience as well.

I implemented 2FA for my previous employer and we would have gladly skipped SMS 2FA if we could get away with it. It's more expensive for the company and the customer. And it sucks to implement because you have to integrate with a phone service. The whole phone system is unreliable or has unexpected problems (e.g. using specific words in a message can get your texts blocked). Problems with the SMS 2FA is a pain for customer service too.

I implemented 2FA at a previous job and I was responsible for the production implementation working as expected. My thoughts were that uncompleted 2FA attempts are common for a number of reasons: typos, someone gets distracted, didn't have access to phone at the time, SMS sucks (either our sending side or the receiving side), etc. I didn't put much thought into it beyond that. (Should I?)

I implemented rate limiting/lockouts for too many 2FA failures. I added the ability to clear the failed attempt count in our customer support portal. If we had any problems after those were implemented, I never heard about them.

You may have to temper your expectations. Free usually means "sells/uses your data to offset costs". If you're OK with that, there's no need to switch off of GMail. If you're not OK with that, you'll have to pay.

Also, hosting email under your own domain gives you the freedom to move from one email provider to another even if they do shut down.

I put my money where my mouth is. I wanted to degoogle and so pay $50/year for Fastmail. One feature I like is automatically snoozing certain emails. Most of my non-personal email is automatically snoozed until 6pm every day. This way I don't get multiple notifications throughout the day for emails that aren't time sensitive.