[GH-ISSUE #122] Password for Root CA key #67

Closed
opened 2026-02-25 22:32:31 +03:00 by kerem · 6 comments
Owner

Originally created by @JoyceBabu on GitHub (Jan 19, 2019).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/122

Is it possible to protect the Root CA key with a password?

Originally created by @JoyceBabu on GitHub (Jan 19, 2019). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/122 Is it possible to protect the Root CA key with a password?
kerem closed this issue 2026-02-25 22:32:31 +03:00
Author
Owner

@FranciscoImanolSuarez commented on GitHub (Jan 23, 2019):

Hi, could you give more details? Check this capable that is what you mean
https://github.com/FiloSottile/mkcert/issues/50

<!-- gh-comment-id:456644669 --> @FranciscoImanolSuarez commented on GitHub (Jan 23, 2019): Hi, could you give more details? Check this capable that is what you mean https://github.com/FiloSottile/mkcert/issues/50
Author
Owner

@JoyceBabu commented on GitHub (Jan 23, 2019):

Thank you for the response.

I was prompted for sudo password when running mkcert -install. But when generating certificates using mkcert no password is required.

Please correct me if I am wrong, but I believe this is a security risk. A malicious script or someone who is given temporary access to my computer can generate an SSL certificate for any domain, which will be trusted on my computer.

If the root key is password protected, then they will need to know the private key password for generating a certificate signed by the local CA.

https://stackoverflow.com/questions/25459512/what-is-diffrent-between-rsa-and-rsa-des3

<!-- gh-comment-id:456668368 --> @JoyceBabu commented on GitHub (Jan 23, 2019): Thank you for the response. I was prompted for sudo password when running `mkcert -install`. But when generating certificates using `mkcert` no password is required. Please correct me if I am wrong, but I believe this is a security risk. A malicious script or someone who is given temporary access to my computer can generate an SSL certificate for any domain, which will be trusted on my computer. If the root key is password protected, then they will need to know the private key password for generating a certificate signed by the local CA. https://stackoverflow.com/questions/25459512/what-is-diffrent-between-rsa-and-rsa-des3
Author
Owner

@moritzdietz commented on GitHub (Jan 25, 2019):

As this CA and its certificates should only be used for local development only and not in production, there does not seem any security problem.

Please bear in mind what your threat model is here - if someone else has physical access to your computer nothing will ever(*) protect you.

<!-- gh-comment-id:457660804 --> @moritzdietz commented on GitHub (Jan 25, 2019): As this CA and its certificates should only be used for local development only and **not** in production, there does not seem any security problem. Please bear in mind what your threat model is here - if someone else has physical access to your computer nothing will ever(*) protect you.
Author
Owner

@JoyceBabu commented on GitHub (Jan 25, 2019):

if someone else has physical access to your computer nothing will ever(*) protect you

While I completely agree with the above point from a theoretical perspective, I am more concerned about the practical possibilities.

Suppose I carelessly leave my laptop unattended for 5 minutes, or naively hand over the laptop to a trusted colleague (who wasn't so trustworthy afterall) temporarily for some reason. I don't think anyone I know or work with can compromise my system in such a short period of time. But the ease of generating certificates usingmkcert opens up an opportunity for creating a trusted certificate even in such a short time.

In the above example, I agree that it is my mistake for leaving the system unattended. But at the same time, it is a highly probable scenario for many of us.

I think mkcert should authenticate the request, by prompting for either the user password or the CA Key password, before generating certificates. CA Private key password is more apt for this. But since mkcert aims to make certificate generation painless, authenticating the request using user password is also okay.

<!-- gh-comment-id:457682217 --> @JoyceBabu commented on GitHub (Jan 25, 2019): > if someone else has physical access to your computer nothing will ever(*) protect you While I completely agree with the above point from a theoretical perspective, I am more concerned about the practical possibilities. Suppose I carelessly leave my laptop unattended for 5 minutes, or naively hand over the laptop to a trusted colleague (who wasn't so trustworthy afterall) temporarily for some reason. I don't think anyone I know or work with can compromise my system in such a short period of time. But the ease of generating certificates using`mkcert` opens up an opportunity for creating a trusted certificate even in such a short time. In the above example, I agree that it is my mistake for leaving the system unattended. But at the same time, it is a highly probable scenario for many of us. I think `mkcert` should authenticate the request, by prompting for either the user password or the CA Key password, before generating certificates. CA Private key password is more apt for this. But since `mkcert` aims to make certificate generation painless, authenticating the request using user password is also okay.
Author
Owner

@FranciscoImanolSuarez commented on GitHub (Jan 26, 2019):

I think that what you propose is more a future idea for the moment I recommend protecting your computer see who shares it, it is a good idea but I do not know how good it is since there are security methods (password protect your computer) that offer the possibility of not having to add this function

<!-- gh-comment-id:457803665 --> @FranciscoImanolSuarez commented on GitHub (Jan 26, 2019): I think that what you propose is more a future idea for the moment I recommend protecting your computer see who shares it, it is a good idea but I do not know how good it is since there are security methods (password protect your computer) that offer the possibility of not having to add this function
Author
Owner

@JoyceBabu commented on GitHub (Jan 26, 2019):

On second thought, authenticating certificate generation requests alone is not enough if the CA private key is unencrypted. It would be easier to steal the private key which can generate unlimited number of certificate, rather than generate and steal a single certificate.

People are usually not very careful with security. Sharing a computer / leaving it unattended are just examples. A software vulnerabilities like JPEG remote code execution exploits are another case which can be used to generate certificate.

I am not really concerned about the computer security here. I am more concerned about someone using the generated certificate for stealing credentials via phishing.

Thank you for considering the request. But it is obvious that you don't consider this a serious risk, and I have failed in convincing you otherwise. mkcert is a very useful tool. I will continue to use it irrespective of whether the feature is implemented or not. Hence I am going ahead and closing the issue.

<!-- gh-comment-id:457815982 --> @JoyceBabu commented on GitHub (Jan 26, 2019): On second thought, authenticating certificate generation requests alone is not enough if the CA private key is unencrypted. It would be easier to steal the private key which can generate unlimited number of certificate, rather than generate and steal a single certificate. People are usually not very careful with security. Sharing a computer / leaving it unattended are just examples. A software vulnerabilities like JPEG remote code execution exploits are another case which can be used to generate certificate. I am not really concerned about the computer security here. I am more concerned about someone using the generated certificate for stealing credentials via phishing. Thank you for considering the request. But it is obvious that you don't consider this a serious risk, and I have failed in convincing you otherwise. `mkcert` is a very useful tool. I will continue to use it irrespective of whether the feature is implemented or not. Hence I am going ahead and closing the issue.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mkcert#67
No description provided.