An account needs to be created before you can request a certificate. Some ACME clients might create the account for you implicitly when you request the first certificate, but in the background it still needs to start by registering an account.
`certbot register` followed by `certbot show_account` is how you'd do this with certbot.
This adds a new validation method that people can use if they want. The existing validation methods (https://letsencrypt.org/docs/challenge-types/) aren't going away, so your current setup will keep working.
And to elaborate, the reasons you might want to use a DNS challenge are to acquire wildcard certificates, or to acquire regular certificates on a machine or domain which isn't directly internet-facing. If neither of those apply to you then the regular HTTP/TLS methods are fine.
OK I was sort of thinking that might be the case but wanted to make sure in case I had to start prepping now, thanks. We use no wildcard domains today, maybe down the road.
Wildcard domains are a great way to get certs for all your "internal systems" with only having to expose one (or a bit of one on DNS) to the Internet at large.
This is going to greatly simplify some of my scripts.
I get why Chrome doesn't want it (it doesn't serve Chrome's interests), but that doesn't explain why Let's Encrypt had to remove it. The reason seems to be "you can't be a Chrome CA and not do exactly what Chrome wants, which is... only things Chrome wants to do". In other words, CAs have been entirely captured by Chrome. They're Chrome Authorities.
Am I the only person that thinks this is insane? All web security is now at the whims of Google?
All major root store programs (Chrome, Apple, Microsoft, Mozilla) have this power. They set the requirements that CAs must follow to be included in their root store, and for most CAs their certs would be useless if they aren't included in all major ones.
I don't think the root programs take these kind of decisions lightly and I don't see any selfish motives they could have. They need to find a balance between not overcomplicating things for site operators and CAs (they must stay reliable) while also keeping end users secure.
A lot of CAs and site operators would love if nothing ever changed: don't disallow insecure signature/hash algorithms, 5+ year valid certs, renewals done manually, no CT, no MPIC, etc. So someone else needs to push for these improvements.
The changes the root programs push for aren't unreasonable, so I'm not really concerned about the power they have over CAs.
That doesn't mean the changes aren't painful in the short term. For example, the move to 45 day certificates is going to cause some downtime, but of course the root programs/browsers don't benefit from that. They're still doing this because they believe that in the long term it's going to make WebPKI more robust.
There's also the CA/Browser Forum where rule changes are discussed and voted on. I'm not sure how root programs decide on what to make part of their root policy vs. what to try to get voted into the baseline requirements. Perhaps in this case Chrome felt that too many CAs would vote against for self-interested reasons, but that's speculation.
The "client cert" requirements were specifically not a CABF rule because that would rule it out for everyone complying with those rules, which is much broader than just the CAs included in Chrome.
Some CAs will continue to run PKIs which support client certs, for use outside of Chrome.
In general, the "baseline requirements" are intended to be just that: A shared baseline that is met by everyone. All the major root programs today have requirements which are unique to their program.
Thanks for chiming in! I remember now that you also said this on the LE community forum.
Right, that explains it. So the use would be for things other than websites or for websites that don't need to support Chrome (and also need clientAuth)?
I guess I find it hard to wrap my head around this because I don't have experience with any applications where this plus a publicly trusted certificate makes sense. But I suppose they must exist, otherwise there would've been an effort to vote it into the BRs.
If you or someone else here knows more about these use cases, then I'd like to hear about it to better understand this.
Are you asking why an HTTPS server would need to use client auth outside of the browser? The answer is mTLS. If you want to use one cert for your one domain to serve both "normal" browser content and HTTPS APIs with mTLS, your cert needs to be able to do it all.
The server that wants to authenticate clients via mTLS doesn't need the clientAuth EKU on its certificate, only the clients do.
Most of the time you set up mTLS by creating your own self-signed certificate and verifying that the client has that cert (or one that chains up to it). I'm wondering what systems exist that need a publicly trusted cert with clientAuth.
Only think I've heard of so far is XMPP for server-to-server auth, but there are alternative auth methods it supports.
Google is much better at this. They always open the map right where I am on my pc (Which does not have gps or WiFi, only internet and I don't allow location in the browser)
On the Google search results page at the bottom there's a city name + "From your IP address" link. Clicking it shows a map with a circled region. It seems to match with what Google maps opens by default.
It's a little less accurate than Cloudflare in my case.
Thanks! I didn't know that. I never use Google search directly anymore, always through SearXNG. So I hadn't noticed. It's indeed about 1km away from my actual location. Not bad. I'm about 500m outside the circle.
You need external monitoring of certificate validity. Your ACME client might not be sending failure notifications properly (like happened to Bazel here). The client could also think everything is OK because it acquired a new cert, meanwhile the certificate isn't installed properly (e.g., not reloading a service so it keeps using the old cert).
I have a simple Python script that runs every day and checks the certificates of multiple sites.
One time this script signaled that a cert was close to expiring even though I saw a newer cert in my browser. It turned out that I had accidentally launched another reverse proxy instance which was stuck on the old cert. Requests were randomly passed to either instance. The script helped me correct this mistake before it caused issues.
100%, I've run into this too. I wrote some minimal scripts in Bash, Python, Ruby, Node.js (JavaScript), Go, and Powershell to send a request and alert if the expiration is less than 14 days from now: https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer... because anyone who's operating a TLS-secured website (which is... basically anyone with a website) should have at least that level of automated sanity check. We're talking about ~10 lines of Python!
There is a Prometheus plugin called ssl_exporter that will provide the ability for Grafana to display a dashboard of all of your certs and their expirations. But, the trick is that you need to know where all your certs are located. We were using Venafi to do auto discovery but a simple script to basically nmap your network provides the same functionality.
What you're monitoring is "Did my system request a renewed cert?" but what most people's customers care about is instead, "Did our HTTPS endpoint use an in-date certificate?"
For example say you've got an internal test endpoint, two US endpoints and a rest-of-world endpoint, physically located in four places. Maybe your renewal process works with a month left - but the code to replace working certificates in a running instance is bugged. So, maybe Monday that renewal happens, your "CT log monitor" approach is green, but nobody gets new certs.
On Wednesday engineers ship a new test release to the test endpoint, restarting and thus grabbing the renewed cert, for them everything seems great. Then on Friday afternoon a weird glitch happens for some US customers, restarting both US servers seems to fix the glitch and now US customers also see a renewed cert. But a month later the Asian customers complain everything is broken - because their endpoint is still using the old certificate.
> Did our HTTPS endpoint use an in-date certificate?
For any non-trivial organization, you want to know when client certificates expire too.
In my experience, the easiest way is to export anything that remotely looks like a certificate to the monitoring system, and let people exclude the false positives. Of course, that requires you to have a monitoring system in the first place. That is no longer a given.
So, I've worked for both startups and large entities, including both an international corporation and a major university, and in all that time I've worked with exactly one system that used client TLS certificates. They mostly weren't from the Web PKI (and so none of these technologies are relevant, Let's Encrypt for example has announced and maybe even implemented choices to explicitly not issue client certs) and they were handled by a handful of people who I'd say were... not experts.
It's true that you could use client certs with say, Entra ID, and one day I will work somewhere that does that. Or maybe I won't, I'm an old man and "We should use client certs" is an ambition I've heard from management several times but never seen enacted, so the renaming of Azure AD to Entra ID doesn't seem likely to change that.
Once you're not using the Web PKI cert expiry lifetimes are much more purpose specific. It might well make sense for your Entra ID apps to have 10 year certs because eh, if you need to kill a cert you can explicitly do that, it's not a vast global system where only expiry is realistically useful. If you're minting your own ten year certs, now expiry alerting is a very small part of your risk profile.
Client certificates aren't as esoteric as you think. They're not always used for web authentication, but many enterprises use them for WiFi/LAN authentication (EAP-TLS) and securing confidential APIs. Shops that run Kubernetes use mTLS for securing pod to pod traffic, etc. I've also seen them used for VPN authentication.
Huh. I have worked with Kubernetes so I guess it's possible that's a second place with client certs and I never noticed.
The big employers didn't use EAP-TLS with client certs. The University of course has Eduroam (for WiFi), and I guess in principle you could use client certs with Eduroam but that sounds like extra work with few benefits and I've never seen it from either the implementation side or the user side even though I've worked on or observed numerous Eduroam installs.
I checked install advice for my language (it might differ in other languages) and there's no sign that Eduroam thinks client certificates would be a good idea. Server certs are necessary to make this system work, and there's plenty of guidance on how to best obtain and renew these certificates e.g. does the Web PKI make sense for Eduroam or should you just busk it? But nothing about client certificates that I could see.
I can't comment on Eduroam as I have no experience working in the Edu space, but in general, EAP-TLS is considered to be the gold standard for WiFi/LAN authentication, as alternatives like EAP-TTLS and PEAP-MSCHAPv2 are all flawed in one way or another and rely on username/password auth, which is a weaker form of authentication than relying on asymmetric cryptography (mTLS). Passwords can be shared and phished, if you're not properly enforcing server cert validation, you will be susceptible to evil twin attacks, etc.
Of course, implementing EAP-TLS usually requires a robust way for distributing client certificates to the clients. If all your devices are managed, this is often done using the SCEP protocol. The CA can be either AD CS, your NAC solution, or a cloud PKI solution like SecureW2.
Yeah, I don't think EAP-TLS with client certs would work out well for Eduroam applications. You have a very large number of end users, they're only barely under your authority (students, not staff) and they have a wide variety of devices, also not under your control.
But even in Enterprise corporate settings I did not ever see this though I'm sure some people do it. It sounds like potentially a good idea, of course it can have excellent security properties, however one of the major downside IMHO is that people wind up with the weakest link being a poorly secured SCEP endpoint. Bad guys could never hope to break the encryption needed to forge credentials, but they could trivially tail-gate a call center worker and get real credentials which work fine, so, who cares.
Maybe that's actually enough. Threat models where adversaries are willing to physically travel to your location (or activate a local asset) might be out of your league anyway. But it feels to me as if that's the wrong way to look at it.
I am airgapped and the certs are usually wildcard with multiple SANs. You would think that the SANs alone would tell you which host has a cert. But, it can be difficult to find all the hosts or even internal hosts that use TLS.
Kind of cool to have an uptime monitoring tool that also had an option like that, two birds one stone and all that. Not affiliated with them, FOSS project.
The scalable way (up to thousands of certificates) is https://sslboard.com. Give it one apex domain, it will find all your in-use certificates, then set alerts (email or webhook). Fully external monitoring and inventory.
Looks like it relies on certificate transparency logs. That means that it won’t be monitor endpoints using wildcard certs. Best thing it could do would be to alert when a wildcard cert is expiring without a renewed cert having been issued.
Is that enough though? You may have wildcards on domains that are not even on a public DNS and you may forget to replace it "somewhere". For that reason it is better to either dump list of domains from your local DNS or have e.g. zabbix or another agent on every host machine checking that file for you.
That's exactly my point. Is that while this service sounds quite useful for many common cases, it's going to fail in cases where there's not a 1-to-1 certificate-to-server mapping. Even outside of wildcards, you have to account for cases where the cert might be installed on N number of load balancers.
If you're using a cert on multiple IPs, or IPv4+v6, SSLBoard will monitor all IPs. It's not foolproof, but it covers most common practices. btw wildcard certs don't have a good reputation (blast radius)...
I'd say that load balancers (one-address-to-N-servers) count as a common practice, but I otherwise agree in that regard.
Regarding wildcard certs, eh. I wouldn't say they have a bad reputation. Sure, greater blast radius. But sometimes it can certainly simplify things to use one. Your ACME client configuration is easier and your TLS terminator configuration often becomes easier when the terminator would otherwise need to switch based on SNI.
one-address-to-N-servers is perfect if the N servers don't all terminate TLS. If not, it becomes impossible to actually test what certificates are actually served. I've seen this fail before (TLS tests flip/flop between good/bad between checks).
As for wildcard certs, I agree there are use cases where we really need them like dynamic subdomains {customer}.status.com
Can you share how they make ACME client configuration easier?
> Can you share how they make ACME client configuration easier?
It's not a profound difference, but you don't need to add each name to your config. Depending on the team's tooling and processes, that may be inconsequential. But in a setting where config management isn't handled super well, where the TLS terminator is a resource shared by multiple, distinct teams, this is a simplification that can make a difference at the margin.
Think less Cloudflare-scale, and more SMB scale (especially in a Windows shop or recovering Windows shop with a different kind of technical culture than what we might all be implicitly imagining).
I'm working on something that could help: linking sslboard with software that's making issuance and distribution of certs easier, ie. a proper CLM. It's not cloud based for security reasons. In that context, we know your wildcard certs because we issue them, and we could know where they are if we distribute them...
Please get in touch with me ([email protected]) if you're interested in early access and having a word in the development of the product!
I didn't realize you were behind SSLBoard. I think you should've disclaimed that involvement at the beginning. I see now that it's in your bio, but disclaiming is still on you.
Indeed, SSLBoard is scanning CT logs. You can add/import host names though, to allow monitoring of wildcard certs. Same if you're using ports that are not 443, you have to add these to the list of hostnames that are checked.
It's not as convenient, but it's the best SSLBoard can do...
You can use systemd-run with --shell (or a subset of options enabled by --shell) and -p to specify service properties to run commands interactively in a similar environment as your service.
This can help troubleshoot issues and makes experimenting with systemd options faster.
I think there's been some talk about adding a built-in way for systemd-run to copy settings out of a .service file, but it doesn't exist yet.
I've written Perl/Python scripts to do this for me. They're not really aimed at working with arbitrary services, but it should be possible to adapt to different scenarios.
There are some gotchas I ran into. For example, with RuntimeDirectory: systemd deletes the directory once the process exits, even if there's still another process running with the same RuntimeDirectory value set.
It's also really useful for doing parallel builds of modules that may actually consume all available memory when you can't force the build system to use fewer cores than you have available.
Both in terms of artificially reducing the number of CPUs you expose, but also in terms of enforcing a memory limit that will kill all processes in the build before the broader kernel OOM killer will act, in case you screw up the number of CPUs.
woah that's actually awesome.
I feel like adding uh storage usage limits could also be easy as well.
But the one thing that I always wonder is about (virtualization?) in the sense of something like docker just for containerizing or some sort of way of running them in some sort of sandbox without much performance issues or something, I am kinda interested in knowing what might be the best way of doing so (is podman the right way or some other way like bubblewrap?)
Edit: just discovered in the comment below the (parents parents?)comment that there is systemd isolation too, that sounds very interesting and the first time I personally heard of it hmm
You can achieve similar results with podman and bubblewrap, but podman handles things like networking, resource and image management that bubblewrap doesn't by itself
Bubblewrap really is more for sandboxing "transient" containers and being able to separate specific things from the host (such as libraries), with other applications handling the image management, which makes sense because its primary user is Flatpak and Steam. Once the application inside the container is exited, the sandbox is destroyed, it's job is done.
Podman is a Docker clone, it's for development or persistent containers. It will monitor containers, restart them, can pull image updates, setup networks between them etc.
They both use namespacing and cgroups under the hood, but for different results and purposes.
Your right that systemd has sandboxing too, and it also uses the same features as the kernel. Podman can also export it's services to be managed by systemd.
There's literally so much choice when it comes to making containers on Linux.
> but podman handles things like networking, resource and image management
Btw, you can do all of this with systemd too
> the sandbox is destroyed, it's job is done.
I think most container systems have an ephemeral option. If you're looking at systemd then look at the man pages for either systemd-nspawn or systemd-vmspawn and look under Image Options. More specifically `-x, --ephemeral`. It's a pretty handy option.
> Podman can also export it's services to be managed by systemd.
But in that case, why not just use systemd? ;)
> There's literally so much choice when it comes to making containers on Linux.
Despite my joke above, I actually love this. Having options is great and I think it ends up pushing all of them to be better. The competition is great. I'm hyping systemd up a bit but honestly there's gives and takes with each of the different methods. There's healthy competition right now, but I do think systemd deserves a bit more love than it currently gets.
Yeah, that is a big drawback. But as mentioned elsewhere and by others, there is `importctl`. So you can ship these images as well. Meaning only one person needs to make that image for others to be able to get the same convenience as pulling a docker image.
I'm unsure if someone has made a tool to convert docker images to systemd. If not, that'd be a pretty handy one.
given that podman can also have a (nicer?) transition to docker is a plus as well.
There are a lot of paas nowadays which use docker under the hood. I think I would love seeing a future where a paas actually manages it using systemd.
I think this might be really nice giving an almost standard way of installing software.
I really want to try to create something like dokku or some gui for making systemd management easier but I will see some alternatives currently, thanks for sharing it!
I'm fairly confident that systemd, docker, podman, bubblewrap, unshare, and probably other tools are all wrapping the same kernel features, so I'd expect a certain degree of convergence in what they provide.
I wrote my comment before I saw yours, but you'll probably be interested in it[0].
The best thing about systemd is also the worst thing: it's monolithic. You can containarize applications lightly all the way to having a full fledged VM. You can run as user or root. You can limit system access like CPU, RAM, network, and even the physical hardware. You even have homed which gives you more control over your user environments. There's systemd mounts[1], boot, machines, timers, networks, and more. It's overwhelming.
I think two commands everyone should know if dealing with systemd services is:
- `systemctl edit foo.service` to create an override file which sits on top of the existing service file (so your changes don't disappear when you upgrade)
- `systemd-analyze security foo.service` which will give you a short description of the security options and a score specifying your exposure level.
These really helped me go down the rabbit hole and I think most people should have some basic idea of how to restrict their services. A little goes a long way, so even if you're just adding `PrivateTmp=yes` to a service, you're improving it.
I've replaced all my cron jobs with systemd jobs now and while it is a bit more work up front (just copy paste templates...) there are huge benefits to be had. Way more flexibility in scheduling and you're not limited to such restrictions as your computer being off[3]
[1] I've found mounts really helpful and can really speed up boot times. You can make your drives mount in the background and after any service you want. You can also set timeouts so that they will power down and automount as needed. That can save you a good amount on electricity if you got a storage service. This might also be a good time to remind people that you likely want to add `noatime` to your mount options (even if you use fstab)[2].
Another issue I just ran into is that a colon separated value for ExecSearchPath doesn't work in systemd-run/-p. You have to specify each path as a separate -p argument.
There are some minor annoyances like that, but it's not too hard to work around.
A code signing certificate does not cost $500 a year. The OP links to an offering by Certum which is just $25 a year plus the cost for a reusable smart card.
Personally, I recently acquired a certificate from HARICA which costs $55 a year if you only buy one year at a time.
