mirror of
https://github.com/FiloSottile/mkcert.git
synced 2026-04-25 13:36:02 +03:00
[GH-ISSUE #143] Support s/mime email certificates #86
Labels
No labels
TLS stack issue
Windows
bug
duplicate
duplicate
enhancement
help wanted
help wanted
pull-request
question
question
root store
waiting for info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mkcert#86
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jcjones on GitHub (Feb 28, 2019).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/143
Given an email address for a command line option, it would be cool to generate certificates suitable for S/MIME use in Thunderbird or Outlook.
@FiloSottile commented on GitHub (Feb 28, 2019):
What would you use an S/MIME certificate that is only valid on your computer for?
@btoews commented on GitHub (Mar 19, 2019):
I would use this for testing development of S/MIME tooling. Would you accept a PR that implemented this?
@FiloSottile commented on GitHub (Mar 19, 2019):
Could we just detect an email address in the names list and generate a cert valid for S/MIME? I’m not familiar with S/MIME myself.
@btoews commented on GitHub (Mar 19, 2019):
If you'd be okay with that. We'd want to either add a DN component or SAN for the email address. We'd also probably want to add key usage for signing and extended key usage for email/code signing.
@FiloSottile commented on GitHub (Mar 19, 2019):
Sounds good to me!
Slight preference for SAN over DN.
Drop the serverAuth EKU if all names are emails. Still respect -client.
@btoews commented on GitHub (Mar 19, 2019):
Cool. I won't be able to look at this for ~2 weeks, but will put it on my todo list unless someone else gets to it first.