Skip to content

tls: plumbing for multiple TLS certificate ingestion.#5095

Merged
htuch merged 3 commits intoenvoyproxy:masterfrom
htuch:multiple-tls-config
Nov 27, 2018
Merged

tls: plumbing for multiple TLS certificate ingestion.#5095
htuch merged 3 commits intoenvoyproxy:masterfrom
htuch:multiple-tls-config

Conversation

@htuch
Copy link
Copy Markdown
Member

@htuch htuch commented Nov 20, 2018

This PR starts to plumb multiple TLS certs from the proto level into the SSL context. We stop short
of enabling multiple TLS certificates, but instead have sufficient mechanism and interface changes
to propagate them to the SSL context. Future PRs will extend this with the SSL context
implementation.

Risk Level: Low
Testing: bazel test //test/...

Part of #1319.

Signed-off-by: Harvey Tuch htuch@google.com

This PR starts to plumb multiple TLS certs from the proto level into the SSL context. We stop short
of enabling multiple TLS certificates, but instead have sufficient mechanism and interface changes
to propagate them to the SSL context. Future PRs will extend this with the SSL context
implementation.

Risk Level: Low
Testing: bazel test //test/...

Part of envoyproxy#1319.

Signed-off-by: Harvey Tuch <htuch@google.com>
return providers;
}
// TODO(htuch): Support multiple SDS secret configs; could we mix them with
// static?
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could mix them (in theory), but we shouldn't, IMHO, and there is no valid reason to do that, really...

tls_certificate_configs_.clear();
tls_certificate_configs_.emplace_back(*tls_certficate_providers_[0]->secret());
callback();
});
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This will break with multiple certificates, clearing list of configured certificates on each callback, won't it? Though, I guess, this will only happen with SDS, where we support only a single certificate right now.

Maybe add a TODO to fix it?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Will add TODO.

const std::string ecdh_curves_;

Ssl::TlsCertificateConfigPtr tls_certificate_config_;
std::vector<Ssl::TlsCertificateConfigImpl> tls_certificate_configs_;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aren't we losing std::unique_ptr wrapping here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, but std::vector is RAII-aware, see https://en.cppreference.com/w/cpp/language/raii.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hmm... I think we're using std::vector<TypePtr> in majority of the codebase...

But if you say it's fine, then it's fine :) Thanks!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, in general you can only do this if the class has a sensible copy/move constructor to allow vector to grow. In this case, TlsCertificateConfigImpl is just a bunch of const strings, so it works fine.

@htuch htuch merged commit 9d1d959 into envoyproxy:master Nov 27, 2018
@htuch htuch deleted the multiple-tls-config branch November 27, 2018 17:18
fredlas pushed a commit to fredlas/envoy that referenced this pull request Mar 5, 2019
This PR starts to plumb multiple TLS certs from the proto level into the SSL context. We stop short
of enabling multiple TLS certificates, but instead have sufficient mechanism and interface changes
to propagate them to the SSL context. Future PRs will extend this with the SSL context
implementation.

Risk Level: Low
Testing: bazel test //test/...

Part of envoyproxy#1319.

Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Fred Douglas <fredlas@google.com>
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.

3 participants