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
Why is it necessary to customize the client TLS renegotiation?
The TPP API server is served by Microsoft Windows Server and IIS.
IIS uses TLS-1.2 by default[1] and it uses a
TLS-1.2 feature called "renegotiation" to allow client certificate
settings to be configured at the folder level. e.g. https://tpp.example.com/vedauth may Require or Accept client
certificates while https://tpp.example.com/vedsdk may Ignore
client certificates.
When IIS is configured this way it behaves as follows[2]:
"Server receives a connection request on port 443; it begins a
handshake. The server does not ask for a client certificate. Once
the handshake is completed, the client sends the actual target URL
as a HTTP request in the SSL tunnel. Up to that point, the server
did not know which page was targeted; it only knew, at best, the
intended server name (through the Server Name Indication). Now
that the server knows which page is targeted, he knows which
"site" (i.e. part of the server, in IIS terminology) is to be
used."
In this scenario, the Go HTTP client MUST be configured to
renegotiate (by default it will refuse to renegotiate).
We use RenegotiateOnceAsClient rather than RenegotiateFreelyAsClient
because cert-manager establishes a new HTTPS connection for each API
request and therefore should only ever need to renegotiate once in this
scenario.
// ConnectorType specify what do you want to use. May be "Cloud", "TPP" or "Fake" for development.
ConnectorType endpoint.ConnectorType
// BaseUrl should be specified for Venafi Platform. Optional for Cloud implementations that do not use https://venafi.cloud/.
BaseUrlstring
// Zone is name of a policy zone in Venafi Platform or Cloud. For TPP, if necessary, escape backslash symbols. For example, "test\\zone" or `test\zone`.
Zonestring
// Credentials should contain either User and Password for TPP connections or an APIKey for Cloud.
Credentials*endpoint.Authentication
// ConnectionTrust may contain a trusted CA or certificate of server if you use self-signed certificate.
ConnectionTruststring// *x509.CertPool
LogVerbosebool
// http.Client to use durring construction
Client*http.Client
}
CURRENT ALTERNATIVES
You can supply a custom http.Client where the transport has been configured with tls.RenegotiateOnceAsClient,
but the disadvantage of this alternative is that you also have to recreate all the other default http.Client settings that are normally set by vcert.
wallrj
changed the title
Allow user to set the vcert client TLS renegotiation setting when accessing TPP servers configured for
Allow user to set the vcert client TLS renegotiation setting when accessing TPP servers
Mar 20, 2024
BUSINESS PROBLEM
Why is it necessary to customize the client TLS renegotiation?
TLS-1.2 feature called "renegotiation" to allow client certificate
settings to be configured at the folder level. e.g.
https://tpp.example.com/vedauth may Require or Accept client
certificates while https://tpp.example.com/vedsdk may Ignore
client certificates.
"Server receives a connection request on port 443; it begins a
handshake. The server does not ask for a client certificate. Once
the handshake is completed, the client sends the actual target URL
as a HTTP request in the SSL tunnel. Up to that point, the server
did not know which page was targeted; it only knew, at best, the
intended server name (through the Server Name Indication). Now
that the server knows which page is targeted, he knows which
"site" (i.e. part of the server, in IIS terminology) is to be
used."
renegotiate (by default it will refuse to renegotiate).
We use RenegotiateOnceAsClient rather than RenegotiateFreelyAsClient
because cert-manager establishes a new HTTPS connection for each API
request and therefore should only ever need to renegotiate once in this
scenario.
PROPOSED SOLUTION
Allow user to supply
tls.RenegotiateOnceAsClient
when configuring the vcert client:vcert/config.go
Lines 52 to 66 in a30535a
CURRENT ALTERNATIVES
You can supply a custom
http.Client
where the transport has been configured withtls.RenegotiateOnceAsClient
,but the disadvantage of this alternative is that you also have to recreate all the other default
http.Client
settings that are normally set by vcert.The text was updated successfully, but these errors were encountered: