How can i delete a CA key while keep using the child certificate for webconf?
-
I created another fake CA, called fake-ca. I then exported a full backup.
Edited the backup file, and copied the second fake ca key and cert onto the first.
I imported back and now everything seems to work.
An even simpler approach to the problem would be a button to overwrite the certs and keys with something clearly marked "destroyed_cert_DO_NOT_TRUST_DO_NOT_USE".
-
Another solution is : Use 'really trusted certificates' => Letsenscrypt using the acme package.
-
You can not get internal names validated.
I could set up a reverse proxy with acme and do all the work there, but then i have to open it to the internet because it has to get validated. So i have put all my unencrypted internal traffic on a machine accessible from the internet.
I use letsencrypt where it should be used, and internal hostnames are not.
In enterprises is trivial to redistribute a new trusted CA through group policies, and then you would have the advantages of having internal trusted certs without the risk and privacy concerns of having a single key that allows mitm and decrypting of every internal communication.
And you can automate it, while the other way of doing this securely (store the key offline) requires manual intervention by design.It moves the point of vulnerability from the storage of the CA private key to the domain admin account.
Simply make a key and a cert, sign a bunch of host certificates, destroy the key, deploy the CA cert.
Trusted fake CAs are not a problem at all if the private key does not exists. :)
-
You can not get internal names validated.
Sure you can. Use an ACME client that uses DNS-01 updates and you can get certs for whatever you want, even things that are not exposed to the Internet, so long as they can update a DNS record.
-
… even things that are not exposed to the Internet, so long as they can update a DNS record.
That how I get the certificates for my internal LAN devices.
The domain is a know domain name on the net - I have a bind server on a Debian server somewhere.
The acme package is using this server - using the nsupdate method to handle all the dirty stuff without exposing anything, neither using proxies or whatever.
Works great. -
"Trusted fake CAs are not a problem at all if the private key does not exists."
Bit of a problem creating new certs though ;) Why would you destroy the key of your CA?
The addition of dns-01 validation with letsencrypt now allows you to use whatever domain does not have to be public available. But I do believe you still have to use a public tld, and they still do not allow rfc1918 space for your SANs… But it going to make it easier for script kiddies to do some mitm stuff ;) While they have some blocked domains, you can get cert for pfsense.org without any issue for example..
This still puts your own local CA way above letsencrypt if you ask me. Big issue I have with letsencrypt is the 90 days.. I can create a cert for local use with 10 years valid, now do not have to deal with that cert again.. Be it automated or not - its a mode of failure that just don't have to deal with.. Not a big deal I guess if you have 1 or 2 of them.. But if your using the certs on more than a handful then it could be a real problem. I use the certs created by CA on pfsense and another one for all my devices that all to replace self signed, etc. Switches, software I run, etc.. Having to change them out every 90 days too much hassle if you ask me. Even though the dns-01 is pretty slick..
But I don't get delete my private key part of using your own local CA.. That tin foil hat is a bit freaking tight ;)
-
You do need a public TLD but they do not need to have A/AAAA records. Only short-lived TXT records while the client runs. Tricky part is finding/using a supported DNS Provider or rolling your own with RFC2136 in something like BIND.
If you access everything by hostname, you don't need RFC1918 SANs. And short of installing your own CA, there won't be a way to make those be trusted anyhow.
Let's Encrypt/ACME will not allow you do to any MITM. It does not let you obtain certificates for things you do not control, and it does not make you a CA such that something like squid could make arbitrary trusted certificates.
As for the 90-day thing, that's why it's all automated. You set it all up once, get the automation working, then you don't have to think about it again.
For me, it's miles ahead of a custom internal CA. I don't have to bother with anything at all on the clients, only the devices where the certificates go.
But as with anything, YMMV. If you want to use an internal CA because you feel it's easier, have at it.
-
"Let's Encrypt/ACME will not allow you do to any MITM. It does not let you obtain certificates for things you do not control"
You are correct - now that look at it closer.. the domain dns still has to have public access. Not internal.. So you have to control the dns for the public domain. Which is still limit to what you can do if you ask me. Where no such limits occur if use use a private CA and your clients trust it.
That being said - it does make it simple for someone that doesn't actually understand how certs work, etc.
I will stick with my private CA thanks anyway.. The only use I can see for letsencrypt would be if you have lots and lots of clients that are out of your control that would access it and you want them to trust. None which comes into play with something like an appliance that would be used by "admins" firewall/switch/router gui, etc. And internally any intranet site that would only be accessed by your clients.. You should have easy methods of having your clients trusting your CA.
But yeah each their own.. I think its a good thing moving towards more and easy https - Only use I have found for them are my hosted sites, where the host has it set up just click and they install the cert, etc.
-
For me, it's miles ahead of a custom internal CA. I don't have to bother with anything at all on the clients, only the devices where the certificates go.
This is the point where you give up all the trust to an automated acme server.
You just get rid of the browser warning, and in the process you loose all the security of the certificate chain scheme, because if I can get a certificate for "pfsense.lan", anybody can, and so there is no point in verifying certificates or using https at all.
If i can just delete a private key, i can deploy how many certificates i want, with decades long validity, without risks because the private key does not exists.
Bit of a problem creating new certs though ;) Why would you destroy the key of your CA?
Those certs do not cost anything, and the risk of a custom CA for and admin is only in having the private key leaked. The risk for your clients is that the admin can MITM https connections.
Destroying the key just after signing new certificates gets rid of those risks.
I can make how many new fakeCAs I want, and there is no overhead in having more CA trusted in your clients.In a home environment, internal names do not change much, so you'll not have too many fakeCAs trusted.
In enterprises, you can manage that centrally so i don't see a problem.
After a while you could redo all the certs on a single new CA, and remove all the others. -
But I don't get delete my private key part of using your own local CA.. That tin foil hat is a bit freaking tight ;)
It's not the tinfoil hat (maybe a bit :) )
It's because of the privacy of the users of the network.
That private key gives the admin the power to intercept https connection of users of his network.
In an enterprise, some witnesses could sign that the admin has destroyed the key, taking that power and responsibility from him.
For an hypothetical hacker trying to escalate privileges in a network finding that private key would make the rest of the job very easy.Destroying a key is totally not unheard in crypto world.
A whole cryptocurrency is based on the trust by everybody that a key used only once has been provably destroyed. -
For me, it's miles ahead of a custom internal CA. I don't have to bother with anything at all on the clients, only the devices where the certificates go.
This is the point where you give up all the trust to an automated acme server.
No, just the trust I'd give any HTTPS web server.
You just get rid of the browser warning, and in the process you loose all the security of the certificate chain scheme, because if I can get a certificate for "pfsense.lan", anybody can, and so there is no point in verifying certificates or using https at all.
That is not how Let's Encrypt/ACME operates. It is not giving a cert for pfsense.lan, and they wouldn't approve that. It's a domain validated certificate. You must prove ownership of the domain name in some way (DNS, HTTP web server response, etc). The domain and hostnames are real, and resolve internally using one of my own personal domains. I use DNS updates, so the A/AAAA records are not public, just the TXT records to renew the domains for a few moments while ACME verifies.
-
That is not how Let's Encrypt/ACME operates. It is not giving a cert for pfsense.lan, and they wouldn't approve that. It's a domain validated certificate. You must prove ownership of the domain name in some way (DNS, HTTP web server response, etc). The domain and hostnames are real, and resolve internally using one of my own personal domains. I use DNS updates, so the A/AAAA records are not public, just the TXT records to renew the domains for a few moments while ACME verifies.
I know that.
You don't get the point. I'm not arguing that you can not do it that way.
I'm saying that-
it's a quite complex mechanism to replace a single signature lasting decades. so to use this at home i need: a domain. a public dns server, a private dns server. And update the certificates on every appliance every 3 months
-
You delegate the validation to another server. if you do not understand this you do not understand how certificate works
Surely it is simple, and if you are not a bit paranoid it is ok. But i repeat: you just get rid of the browser warning.
-
-
I get it and understand it fine, thanks.
You said:
because if I can get a certificate for "pfsense.lan", anybody can, and so there is no point in verifying certificates or using https at all.
Which is not true for the reasons I stated. Nobody else can get a certificate for my firewall hostnames, because they could not pass the required validation.
And LE may be complex at first, but it almost forces you to setup automation. Changing keys every 3 months is more secure and is already done by sites covering ~30% of TLS transactions.
The good thing is, you can keep running yours exactly like you want, and I can keep doing mine my way, and they both work OK for the scenarios where they make sense.
If you don't like LE, don't use it, but if you don't understand it, don't discourage others from using it.
-
because if I can get a certificate for "pfsense.lan", anybody can, and so there is no point in verifying certificates or using https at all.
Which is not true for the reasons I stated. Nobody else can get a certificate for my firewall hostnames, because they could not pass the required validation.
And LE may be complex at first, but it almost forces you to setup automation. Changing keys every 3 months is more secure and is already done by sites covering ~30% of TLS transactions.
You are right. Sorry, english is not my native language. What i really meant was " if i COULD get…". I know you can't.
As i already said, I know how complex LE is, and i already use it from the beginning, setting up the required automation. And i love it!
But you know what certificate transparency logs are, do you? Because I want to keep my internal hostnames private. Even more in a company.
This is a good and private security model. And can secure also IP addresses. While LE cant.
Everyone can do it the way he wants, but right now, you can do it your way from the GUI, while I can't (without an ugly hack).
