starred/mkcert

Fork 0

mirror of https://github.com/FiloSottile/mkcert.git synced 2026-04-25 05:26:03 +03:00

[GH-ISSUE #343] Expiration #225

New issue

Open

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

kerem commented

2026-02-25 22:32:54 +03:00

Owner

Originally created by @lollita on GitHub (Feb 21, 2021).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/343

Do it is possible to set custom expiration date?

Originally created by @lollita on GitHub (Feb 21, 2021). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/343 Do it is possible to set custom expiration date?

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

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

github.com/FiloSottile/mkcert@0a3190b165/cert.go (L59-L62)
expiration period is hardcoded here, and the comment tells the reason of the value.

@ikeyan commented on GitHub (Feb 26, 2021): https://github.com/FiloSottile/mkcert/blob/0a3190b1659e514d6e9b03eedfa25049d046000b/cert.go#L59-L62 expiration period is hardcoded here, and the comment tells the reason of the value.

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

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

if this is a feature request, maybe duplicate of https://github.com/FiloSottile/mkcert/issues/339.

@ikeyan commented on GitHub (Feb 26, 2021): if this is a feature request, maybe duplicate of https://github.com/FiloSottile/mkcert/issues/339.

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@andykais commented on GitHub (May 24, 2021):

maybe expose this as an option and if a user exceeds the macos maximum expiration date, log a warning? Also, I'll be honest I am new to certificates, but I think that a cert generated on linux or windows is not valid on mac, and vice versa because it is tied to a root cert that is specific to that OS. So if we detect what OS the cert is being generated for, we could avoid even logging that error for non-macs.

The big use case for me is distributing a localhost web app as a linux package. The certificate doesn't ever need to expire in that case, and it would be frustrating for users to see an error in their app that their cert expired 2 years later

@andykais commented on GitHub (May 24, 2021): maybe expose this as an option and if a user exceeds the macos maximum expiration date, log a warning? Also, I'll be honest I am new to certificates, but I _think_ that a cert generated on linux or windows is not valid on mac, and vice versa because it is tied to a root cert that is specific to that OS. So if we detect what OS the cert is being generated for, we could avoid even logging that error for non-macs. The big use case for me is distributing a localhost web app as a linux package. The certificate doesn't _ever_ need to expire in that case, and it would be frustrating for users to see an error in their app that their cert expired 2 years later

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@prasanthbazz commented on GitHub (Jul 31, 2021):

@andykais Certificates are platform/ OS neutral AFAIK. It is the way we install certificate to the OS certificate store differ between OS.

@prasanthbazz commented on GitHub (Jul 31, 2021): @andykais Certificates are platform/ OS neutral AFAIK. It is the way we install certificate to the OS certificate store differ between OS.

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@rubencodes commented on GitHub (Mar 14, 2022):

Follow-up question on this - is there any way to detect an expired certificate? So I can create + trust a new one?

@rubencodes commented on GitHub (Mar 14, 2022): Follow-up question on this - is there any way to detect an expired certificate? So I can create + trust a new one?

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@ronaaron commented on GitHub (Aug 10, 2025):

I would definitely appreciate an option to set the certificate expiration in number of days. Thank you!

@ronaaron commented on GitHub (Aug 10, 2025): I would definitely appreciate an option to set the certificate expiration in number of days. Thank you!

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@ed2050 commented on GitHub (Nov 25, 2025):

// Certificates last for 2 years and 3 months, which is always less than
// 825 days, the limit that macOS/iOS apply to all certificates,
// including custom roots. See https://support.apple.com/en-us/HT210176.
expiration := time.Now().AddDate(2, 3, 0)

expiration period is hardcoded here, and the comment tells the reason of the value.

Actually that link only mentions server certificate expiry:
"TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate)."

There's nothing about custom roots. Where did you get that info from?

@ed2050 commented on GitHub (Nov 25, 2025): > // Certificates last for 2 years and 3 months, which is always less than > // 825 days, the limit that macOS/iOS apply to all certificates, > // including custom roots. See https://support.apple.com/en-us/HT210176. > expiration := time.Now().AddDate(2, 3, 0) > > expiration period is hardcoded here, and the comment tells the reason of the value. Actually [that link](https://support.apple.com/en-us/HT210176) only mentions server certificate expiry: "TLS *server certificates* must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate)." There's nothing about custom roots. Where did you get that info from?

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@ed2050 commented on GitHub (Nov 25, 2025):

The big use case for me is distributing a localhost web app as a linux package. The certificate doesn't ever need to expire in that case, and it would be frustrating for users to see an error in their app that their cert expired 2 years later

Did you ever solve this? I'm in similar situation. 2 years is far too short for local root CA.

@ed2050 commented on GitHub (Nov 25, 2025): > The big use case for me is distributing a localhost web app as a linux package. The certificate doesn't _ever_ need to expire in that case, and it would be frustrating for users to see an error in their app that their cert expired 2 years later Did you ever solve this? I'm in similar situation. 2 years is far too short for local root CA.

kerem commented

2026-02-25 22:32:54 +03:00

Author

Owner

@redoper1 commented on GitHub (Dec 1, 2025):

mkcert/cert.go

Lines 59 to 62 in 0a3190b

// Certificates last for 2 years and 3 months, which is always less than
// 825 days, the limit that macOS/iOS apply to all certificates,
// including custom roots. See https://support.apple.com/en-us/HT210176.
expiration := time.Now().AddDate(2, 3, 0)

expiration period is hardcoded here, and the comment tells the reason of the value.

Yeah, it's hardcoded, but it would be great if we could set shorter expire date in days for testing purposes by some flag. Default could be as it is.

@redoper1 commented on GitHub (Dec 1, 2025): > [mkcert/cert.go](https://github.com/FiloSottile/mkcert/blob/0a3190b1659e514d6e9b03eedfa25049d046000b/cert.go#L59-L62) > > Lines 59 to 62 in [0a3190b](/FiloSottile/mkcert/commit/0a3190b1659e514d6e9b03eedfa25049d046000b) > > // Certificates last for 2 years and 3 months, which is always less than > // 825 days, the limit that macOS/iOS apply to all certificates, > // including custom roots. See https://support.apple.com/en-us/HT210176. > expiration := time.Now().AddDate(2, 3, 0) > > expiration period is hardcoded here, and the comment tells the reason of the value. Yeah, it's hardcoded, but it would be great if we could set shorter expire date in days for testing purposes by some flag. Default could be as it is.