Correct. If using actual pki with a trusted root and private CA, you’re just fine.
I took the statement to mean ad-hoc self-signed certs, signed by the server that they are deployed on. That works for EiT but defeats any MitM protection, etc.
I use self signed certs for thinclient authentication. Generate self signed cert, load into AWS workspaces, sign device certs with root, and only machines that have the cert installed and pass the username password prompt will get through the AWS service broker. I can’t see how using a CA signed cert helps me in any meaningful way. If I lose trust in the cert, I revoke it myself from the service.
Use of a CA (private CA would be my thought in this case) gives you greater ability to manage certs without needing to manually revoke and the ability to verify authenticity. You’re already doing most of the work to run a private CA, TBH. Just, instead of signing from the machine, you add your private CA’s intermediate cert to the trusted CAs on your hosts, and generate CSRs on your new hosts for your CA to sign.
Signing from the machine that uses a cert gives it greater authority and increases the “blast radius” if it gets compromised.
I do have a private ca service running on an internal ec2 instance, but all the AWS workspaces broker checks is if the device cert being passed by the thinclient was signed by one of the two signing certs you’ve loaded into the service, so the private ca itself still doesn’t manage revocation in this case.
I do appreciate the suggestion. My main goal in sharing this use case was to show folks that there are many places certificate are used that let’s encrypt isn’t geared up to solve. Other examples are things like signing Microsoft API requests, etc.
At the point of running your own CA with infrastructure in place to support it, I wouldn’t really call that “self signing.”
I get that it technically is, since you’re not going through an external CA, but really it’s like calling a companies Datacenter “self hosted” because it’s on their own hardware. Technically the truth, but not what is generally meant. 😜
I didn’t say anything that disagrees with this. CAs are nice and convenient. They do this by expanding the chain of trust to a lot more people, hence making them less secure.
Sure if you can’t securely manage your cert, that’s a problem. But that doesn’t mean let’s less secure
Why would anyone ever use self signed certs? Buy a cheap ass domain, and use LetsEncrypt to get a free cert.
If it is for internal only, self signed is a lot easier.
Also probably no sysadmin uses it, but the Gemini protocol requires the use of a self signed cert
Hard disagree. As long as you have any machine with internet access it’s trivial, even more so if you can use DNS challenge.
You’re absolutely correct. For self hosting at home I use cloudflare for DNS challenges.
Caddy is also amazing at making things even simpler.
So is using “pass” as the password to all of your sensitive systems. Still not best, or even good practice.
Are you conflating self-signed and untrusted?
Self-signed is fine if you have a trusted root deployed across your environment.
Correct. If using actual pki with a trusted root and private CA, you’re just fine.
I took the statement to mean ad-hoc self-signed certs, signed by the server that they are deployed on. That works for EiT but defeats any MitM protection, etc.
I use self signed certs for thinclient authentication. Generate self signed cert, load into AWS workspaces, sign device certs with root, and only machines that have the cert installed and pass the username password prompt will get through the AWS service broker. I can’t see how using a CA signed cert helps me in any meaningful way. If I lose trust in the cert, I revoke it myself from the service.
Use of a CA (private CA would be my thought in this case) gives you greater ability to manage certs without needing to manually revoke and the ability to verify authenticity. You’re already doing most of the work to run a private CA, TBH. Just, instead of signing from the machine, you add your private CA’s intermediate cert to the trusted CAs on your hosts, and generate CSRs on your new hosts for your CA to sign.
Signing from the machine that uses a cert gives it greater authority and increases the “blast radius” if it gets compromised.
I do have a private ca service running on an internal ec2 instance, but all the AWS workspaces broker checks is if the device cert being passed by the thinclient was signed by one of the two signing certs you’ve loaded into the service, so the private ca itself still doesn’t manage revocation in this case.
I do appreciate the suggestion. My main goal in sharing this use case was to show folks that there are many places certificate are used that let’s encrypt isn’t geared up to solve. Other examples are things like signing Microsoft API requests, etc.
Anyway, have a great day!
Oh fun. Thanks for sharing! Have a great day, yourself!
deleted by creator
Mtls across a large number of machines. I run my own CA and intermediates on hashicorp vault.
For end user services, yes LE.
At the point of running your own CA with infrastructure in place to support it, I wouldn’t really call that “self signing.”
I get that it technically is, since you’re not going through an external CA, but really it’s like calling a companies Datacenter “self hosted” because it’s on their own hardware. Technically the truth, but not what is generally meant. 😜
What’s LE?
Let’s encrypt
Self signed certs are more secure. You don’t have to trust the whole CA chain
deleted by creator
I didn’t say anything that disagrees with this. CAs are nice and convenient. They do this by expanding the chain of trust to a lot more people, hence making them less secure.
Sure if you can’t securely manage your cert, that’s a problem. But that doesn’t mean let’s less secure
deleted by creator