-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Certificate renewal in CPS #28
Comments
There are a major problem, which also affects to TLS, with DV certificates. All these certificates are domain based certificates. Thus, the control of the domain (the email account for S/MIME) is the only requirement to issue a certificate. If an attacker may request successfully a certificate of your email account, it implies that it is under its control and, thus, from the server perspective, it is a legit account. This also happens with, for instance, Let's Encrypt. If an attacker takes the control of your domain, it will be able to issue new certificates for your domain and keep them under its control. The same applies for emails and S/MIME. Said that, regarding with Mozilla Root Store Policy, we do not think that violate them. CPS states that the renewals are treated as new applications. This is because Certbot does not allow to renew a certificate with CSR without making a complete new order. This is not bad but probably it could be optimized. What CASTLE CA does is to revoke all certificates that are valid when receive a new request with an existing email address in its database. Therefore, if an attacker steals your account and issues a certificate, when you recover the control of your email account you must to request a new certificate in order to revoke the bad one (attacker's cert). When CASTLE CA receive a new order with the same email account, all previous certificates that match are revoked. You can do the test. Perform two request and check that the first cert is revoked. You can do check it with the CASTLE OCSP service. |
Any news here?
That's different, TLS certificates have certificate transparency, shorter validity periods, and are much more difficult to exploit, after the domain owner has reclaimed her domain.
I appreciate this, but I cant find this process in your CPS where you have to describe this. |
You can use this issue tracker or contact through the web/email.
Certainly, S/MIME certs do no have the equivalent CT infrastructure. This is the reason of impulsing and promoting our transparency portal, where all issued S/MIME certs are publicly displayed (with email obfuscation). https://acme.castle.cloud/acme/certificates/
We've updated CPS to include this clarification. |
Thanks for the update |
Is there a project/issue tracker for the ACMECastle service? I'm writing here, because I couldn't find any.
Your CPS states:
This contradicts with Mozilla Root Store Policy:
When my email account gets compromised, I have no possibility to revoke certificates an attacker creates with it, because I neither have the account key nor the certificate private key in this case. Wouldn't it be better to revoke all valid certificates with matching SAN and keyUsages upon renewal to prevent this?
The text was updated successfully, but these errors were encountered: