[GH-ISSUE #260] Specify CA Name on mkcert -install #169

Open
opened 2026-02-25 22:32:47 +03:00 by kerem · 9 comments
Owner

Originally created by @mfoster86 on GitHub (May 1, 2020).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/260

Would like to request the ability to specify a name for the CA certificate's subject common name when running mkcert -install.

Example: mkcert -instal -name 'My Dev CA 01'

The built-in method for generating the CN of the CA certificate uses parenthesis in the name which have to be escaped properly in certain languages, bash as an example.

Originally created by @mfoster86 on GitHub (May 1, 2020). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/260 Would like to request the ability to specify a name for the CA certificate's subject common name when running `mkcert -install`. Example: `mkcert -instal -name 'My Dev CA 01'` The built-in method for generating the CN of the CA certificate uses parenthesis in the name which have to be escaped properly in certain languages, bash as an example.
Author
Owner

@FiloSottile commented on GitHub (Oct 25, 2020):

This is a common request, but I prefer not to make the root customizable for a few reasons:

  1. The UX is unclear, what happens if you re-run -install without -name or with a different -name? Does it destroy the current root?
  2. There are too many customization options, so we'd need full Subject syntax, and probably also something for the names on the leaf certificates
  3. mkcert is targeted at development. It happens to work as a private CA with one user, but scaling past that with mkcert is not using it for what it's designed, and customizable names encourage that.

If parens are annoying, we can remove them. Can you tell us more about how you're using the root to understand what would work?

<!-- gh-comment-id:716197706 --> @FiloSottile commented on GitHub (Oct 25, 2020): This is a common request, but I prefer not to make the root customizable for a few reasons: 1. The UX is unclear, what happens if you re-run -install without `-name` or with a different `-name`? Does it destroy the current root? 2. There are too many customization options, so we'd need full Subject syntax, and probably also something for the names on the leaf certificates 3. mkcert is targeted at development. It happens to work as a private CA with one user, but scaling past that with mkcert is not using it for what it's designed, and customizable names encourage that. If parens are annoying, we can remove them. Can you tell us more about how you're using the root to understand what would work?
Author
Owner

@mfoster86 commented on GitHub (Oct 25, 2020):

That makes sense on wanting to keep it development focused and not customizable. If removing the parentheses is possible then that would be great.

I tried to remember specifically what use case I was testing mkcert with at the time of posting this, but honestly cannot remember. I was probably testing a certificate scenario using a combination of Python/bash and ran into a character escaping problem with the parentheses.

<!-- gh-comment-id:716204300 --> @mfoster86 commented on GitHub (Oct 25, 2020): That makes sense on wanting to keep it development focused and not customizable. If removing the parentheses is possible then that would be great. I tried to remember specifically what use case I was testing mkcert with at the time of posting this, but honestly cannot remember. I was probably testing a certificate scenario using a combination of Python/bash and ran into a character escaping problem with the parentheses.
Author
Owner

@luxueyan commented on GitHub (Feb 26, 2021):

Some app must run in LAN. It need be customed

<!-- gh-comment-id:786381950 --> @luxueyan commented on GitHub (Feb 26, 2021): Some app must run in LAN. It need be customed
Author
Owner

@eleven-net-cn commented on GitHub (Oct 17, 2022):

Sometimes we generate certificates that are shared by the team during the development phase,It would be better to allow custom name.

<!-- gh-comment-id:1280398484 --> @eleven-net-cn commented on GitHub (Oct 17, 2022): Sometimes we generate certificates that are shared by the team during the development phase,It would be better to allow custom name.
Author
Owner

@laudukang commented on GitHub (Nov 4, 2022):

I'm really looking forward to this feature.

<!-- gh-comment-id:1303079227 --> @laudukang commented on GitHub (Nov 4, 2022): I'm really looking forward to this feature.
Author
Owner

@c33s commented on GitHub (Feb 1, 2024):

especially in the development phase it customization is important. as developer who thinks about his variable names carefully i would really prefer to set a custom name (and maybe later much more). the custom name would help me in team development and also i would love to name the cert something like AAA.... to keep it at the top of all certs.

from user security point of view we could also argue that a development certificate with an "unknown" name (a name not chosen by myself), can lead to forget such a cert in the browser which could lead to misuse from people who want to do harm.

trying to protect developers is a noble cause but in the end it is annoying most of the time. it leaves an odd feeling as if someone other is thinking for you.

so this is my vote for customizing the name.

<!-- gh-comment-id:1922370812 --> @c33s commented on GitHub (Feb 1, 2024): especially in the development phase it customization is important. as developer who thinks about his variable names carefully i would really prefer to set a custom name (and maybe later much more). the custom name would help me in team development and also i would love to name the cert something like `AAA....` to keep it at the top of all certs. from user security point of view we could also argue that a development certificate with an "unknown" name (a name not chosen by myself), can lead to forget such a cert in the browser which could lead to misuse from people who want to do harm. trying to protect developers is a noble cause but in the end it is annoying most of the time. it leaves an odd feeling as if someone other is thinking for you. so this is my vote for customizing the name.
Author
Owner

@schontz commented on GitHub (Mar 4, 2025):

What name does mkcert currently used? I ran mkcert -install and I can't readily find the certs in Keychain on macOS.

<!-- gh-comment-id:2697975888 --> @schontz commented on GitHub (Mar 4, 2025): What name does mkcert currently used? I ran `mkcert -install` and I can't readily find the certs in Keychain on macOS.
Author
Owner

@levymetal commented on GitHub (Jul 2, 2025):

What name does mkcert currently used? I ran mkcert -install and I can't readily find the certs in Keychain on macOS.

In MacOS these are installed in the System keychain, and the Common Name will be mkcert username@hostname where username is your login name and hostname is the host name reported by the kernel.

<!-- gh-comment-id:3026102102 --> @levymetal commented on GitHub (Jul 2, 2025): > What name does mkcert currently used? I ran `mkcert -install` and I can't readily find the certs in Keychain on macOS. In MacOS these are installed in the System keychain, and the Common Name will be `mkcert username@hostname` where `username` is your login name and `hostname` is the host name reported by the kernel.
Author
Owner

@DoraTheExploder commented on GitHub (Aug 7, 2025):

I've discovered that if you use an external tool to generate a Certificate Signing Request (.csr) such as DigiCert CSR Tool (or do it manually with openssl), you can customize the relevant fields and then pass it as a sort of configuration file to mkcert with $ mkcert -csr <domain>.

I have not tested using a CSR for initial Root CA installation, but $ mkcert --help implies that it should be possible.

<!-- gh-comment-id:3165324857 --> @DoraTheExploder commented on GitHub (Aug 7, 2025): I've discovered that if you use an external tool to generate a Certificate Signing Request (.csr) such as [DigiCert CSR Tool](https://www.digicert.com/easy-csr/openssl.htm) (or do it manually with openssl), you can customize the relevant fields and then pass it as a sort of configuration file to mkcert with `$ mkcert -csr <domain>`. I have not tested using a CSR for initial Root CA installation, but `$ mkcert --help` implies that it should be possible.
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#169
No description provided.