You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Nexus has external APIs for CRUD of "system-wide" x.509 TLS certificates. Nexus uses one of these configured TLS certificates for the external API's HTTP server.
The problem: TLS certificates are generally associated with a specific DNS Name, and each Silo will have its own DNS name. See RFD 357 for more on this.
I think the right approach here will be:
These certificate management APIs should probably move under the Silo level and manage certificates for a particular Silo's public endpoint. There will be no system-wide certificates because there is no system-wide HTTPS endpoint.
We need to use TLS SNI to select the right certificate for a particular incoming TCP connection. I've confirmed that rustls supports this by providing a ResolvesServerCertUsingSni when building the rustls::Config.
Today, in omicron_nexus::app::certificate::Nexus::get_nexus_tls_config(), we load all the system-wide certificates, pick one, use it to make a new dropshot::ConfigTls with that certificate. I think instead we're going to want to load every Silo's certificate (picking one for each Silo). Then we're going to want a new dropshot::ConfigTls variant that lets Omicron specify the certificate resolver (or else provides the information needed for Dropshot to do that, which would be something like a map of server names to certificates). I think much of the code around this won't need to change beyond that.
The text was updated successfully, but these errors were encountered:
Currently Nexus has external APIs for CRUD of "system-wide" x.509 TLS certificates. Nexus uses one of these configured TLS certificates for the external API's HTTP server.
The problem: TLS certificates are generally associated with a specific DNS Name, and each Silo will have its own DNS name. See RFD 357 for more on this.
I think the right approach here will be:
ResolvesServerCertUsingSni
when building therustls::Config
.omicron_nexus::app::certificate::Nexus::get_nexus_tls_config()
, we load all the system-wide certificates, pick one, use it to make a new dropshot::ConfigTls with that certificate. I think instead we're going to want to load every Silo's certificate (picking one for each Silo). Then we're going to want a newdropshot::ConfigTls
variant that lets Omicron specify the certificate resolver (or else provides the information needed for Dropshot to do that, which would be something like a map of server names to certificates). I think much of the code around this won't need to change beyond that.The text was updated successfully, but these errors were encountered: