Skip to content
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

Add support for certificates with client and server auth and URL SANs #166

Merged
merged 6 commits into from
Jul 5, 2019

Conversation

robertpanzer
Copy link
Contributor

Thank you for this awesome tool! :-)

I wanted to use it to create certificates for a Service Mesh, that is for using Istio with mTLS without using Citadel.
Therefore I needed to create certificates that have an extended key usage of client and server auth.
I also needed to have Spiffe URIs in the Subject Alternate Names.

Therefore I did the following changes:

  1. Add a new flag -server which is enabled by default. If set to false and setting -client=true a client-only certificate would be generated, with -client=true and -server=true (the default) a client and server certificate would be created.
  2. Check the hostnames for being a URI with a non-empty scheme. In that case the name is accepted and added as a URI SAN.

Copy link
Owner

@FiloSottile FiloSottile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are changing the default of mkcert -client to client+server, we might as well not add the -server flag, and make -client mean client+server. I don't see that breaking anything.

Also, please split the URL support into a separate commit (or PR).

@robertpanzer
Copy link
Contributor Author

Thanks for the feedback!
I am currently on PTO and will update the PR as soon as I’m back.

@robertpanzer
Copy link
Contributor Author

@FiloSottile I updated the PR according to your requests: It consists of 2 commits now, the first only adds support for URLs as SANs, the second adds the extended key usage server auth for client certs.

Copy link
Owner

@FiloSottile FiloSottile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! The second commit looks good, made a couple comments about the first.

main.go Outdated
@@ -194,6 +195,9 @@ func (m *mkcert) Run(args []string) {
if email, err := mail.ParseAddress(name); err == nil && email.Address == name {
continue
}
if _, err := url.Parse(name); err == nil {
continue
}
punycode, err := idna.ToASCII(name)
if err != nil {
log.Fatalf("ERROR: %q is not a valid hostname, IP, or email: %s", name, err)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and below, update the error.

main.go Outdated
@@ -194,6 +195,9 @@ func (m *mkcert) Run(args []string) {
if email, err := mail.ParseAddress(name); err == nil && email.Address == name {
continue
}
if _, err := url.Parse(name); err == nil {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing the extra validation that happens in cert.go.

cert.go Outdated
@@ -70,13 +71,15 @@ func (m *mkcert) makeCert(hosts []string) {
tpl.IPAddresses = append(tpl.IPAddresses, ip)
} else if email, err := mail.ParseAddress(h); err == nil && email.Address == h {
tpl.EmailAddresses = append(tpl.EmailAddresses, h)
} else if uriName, err := url.Parse(h); err == nil && uriName.Scheme != "" {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit worried this will catch things some people want as hostnames. Anything with a : will parse as an URI with Scheme != "", and sometimes people use : in hostnames, for example.

Are there other filters we can apply while still working for your use case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my concrete use case I want Spiffe URIs, so checking for value URLs plus the prefix spiffe:// would be fine too (for me)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update the PR to require the scheme spiffe.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to make it Spiffe specific. Looks like those are URLs with the full ://, so we can just check Scheme != "" && Host != "" (because without :// only Scheme and Opaque get populated).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Just updated the PR with this check.

@robertpanzer
Copy link
Contributor Author

Just updated the PR by fixing the error message and only supporting spiffe URIs for now.

main.go Outdated Show resolved Hide resolved
main.go Outdated Show resolved Hide resolved
@FiloSottile
Copy link
Owner

LGTM with a minor nit (see suggestions).

robertpanzer and others added 2 commits June 17, 2019 19:20
Co-Authored-By: Filippo Valsorda <hi@filippo.io>
Co-Authored-By: Filippo Valsorda <hi@filippo.io>
@robertpanzer
Copy link
Contributor Author

Thank you! Sorry for forgetting about this.

@FiloSottile FiloSottile merged commit c2b30c4 into FiloSottile:master Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants