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

return auto_encrypt cert for listeners #6489

Merged
merged 8 commits into from
Nov 12, 2019
Merged

Conversation

hanshasselberg
Copy link
Member

@hanshasselberg hanshasselberg commented Sep 16, 2019

Fixes #6403

return c.manual.cert, nil
cert := c.manual.cert
if cert == nil {
cert = c.autoEncrypt.cert
Copy link
Member

Choose a reason for hiding this comment

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

can c.autoEncrypt ever be nil? If it is this will panic.

Copy link
Member Author

Choose a reason for hiding this comment

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

NewConfigurator initializes it:

consul/tlsutil/config.go

Lines 169 to 176 in ef52147

func NewConfigurator(config Config, logger *log.Logger) (*Configurator, error) {
c := &Configurator{logger: logger, manual: &manual{}, autoEncrypt: &autoEncrypt{}}
err := c.Update(config)
if err != nil {
return nil, err
}
return c, nil
}
.

Copy link
Member

@banks banks left a comment

Choose a reason for hiding this comment

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

Couple of points in tests but the code looks good.

One inline but a meta one: the significant behaviour change here is in GetCertificate yet the tests have no diff that mentions that method? How are we testing the actual change here that GetCertificate now returns auto TLS?

require.NoError(t, err)
require.Equal(t, c.autoEncrypt.cert, cert)

c.manual.cert = &tls.Certificate{Certificate: [][]byte{}}
Copy link
Member

Choose a reason for hiding this comment

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

Should we add some actual payload to this Certificate that means it can't accidentally compare equal to the auto one above due to deep-equals rather than exact pointer checking?

I'm actually not sure this assertion prooves anything currently because I think it would still pass even if we were returning the auto cert not the manual cert after this since they both have equivalent values and require.Equal does a deep equality not a pointer match IIRC.

Making them obviously different would make the intent of this test clearer too.

@hanshasselberg
Copy link
Member Author

Thanks for the review @banks! I addressed your points and made the tests more meaningful. And improved the code as well.

@@ -351,7 +351,7 @@ func (c *Config) baseVerifyIncoming() bool {

func loadKeyPair(certFile, keyFile string) (*tls.Certificate, error) {
if certFile == "" || keyFile == "" {
return &tls.Certificate{}, nil
return nil, nil
Copy link
Member Author

Choose a reason for hiding this comment

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

Returning an empty cert here led to all kinds of strange things. This is gone now for good.

Copy link
Member

@banks banks left a comment

Choose a reason for hiding this comment

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

Changes look good to me. I realise @i0rek is not likely to be around to make the small comment tweak suggested here or merge but we can find someone else who can hopefully!

require.NoError(t, err)
require.Equal(t, c.autoEncrypt.cert, cert)

c2, err := loadKeyPair("../test/key/ourdomain.cer", "../test/key/ourdomain.key")
Copy link
Member

Choose a reason for hiding this comment

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

nit: this test looks good now but it might not be obvious to future us exactly what the signficance f this behaviour is.

Maybe add comments that adding one cert as the auto_encrypt one gets returned as the regular server cert above and then that loading a different one as well as the "manual" cert means we still server the manual one not the auto-encrypt one.

@mikemorris mikemorris self-assigned this Sep 23, 2019
for empty string certFile or keyFile arg
@mikemorris mikemorris merged commit a3f4910 into master Nov 12, 2019
@mikemorris mikemorris deleted the auto_encrypt_get_cert branch November 12, 2019 18:40
mikemorris added a commit that referenced this pull request Nov 12, 2019
mikemorris pushed a commit that referenced this pull request Nov 12, 2019
* fix cert check

* fix lock

* add tests

* test: add comments describing expected behavior for auto-encrypt and manual certificates

* test: expect nil *tls.Certificate for empty string certFile or keyFile arg
mikemorris added a commit that referenced this pull request Nov 12, 2019
@hanshasselberg hanshasselberg mentioned this pull request Dec 13, 2019
2 tasks
@ghost
Copy link

ghost commented Jan 25, 2020

Hey there,

This issue has been automatically locked because it is closed and there hasn't been any activity for at least 30 days.

If you are still experiencing problems, or still have questions, feel free to open a new one 👍.

@ghost ghost locked and limited conversation to collaborators Jan 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use certificates generated by auto_encrypt for HTTPS API and not only RPC
3 participants