This PR adds the ability to configure certificate validation in different ways, for the SSL/TLS certificates used to establish a HTTPS connection.
When using self-signed certificates, it's a common feature to provide the ability to determine how a certificate is validated. With this feature, four modes are provided:
CertificateValidation::Default:
This is the default validation implementation, and is essentially a no-op. It's provided simply as a means to change from a different validation mode, which is useful in testing this feature.
CertificateValidation::Full(Certificate):
Validates that the certificate provided by the server is signed by a trusted Certificate Authority (CA) and also verifies that the server’s hostname (or IP address) matches the names identified by the CommonName (CN) or Subject Alternative Name (SAN) within the certificate. Typically, the certificate provided to the client will the Certificate Authority (CA) used to generated the certificate.
CertificateValidation::Certificate(Certificate):
Validates that the certificate provided by the server is signed by a trusted Certificate Authority (CA), but does not perform hostname verification. Typically, the certificate provided to the client will be the Certificate Authority (CA) used to generated the certificate, and is useful for self-signed certificates that do not contain the CommonName (CN) or a Subject Alternative Name (SAN) that matches the server hostname.
CertificateValidation::None:
No validation on a provided certificate. This is intended only for development purposes and is strongly discouraged for use in production.
This PR makes several enhancements to the CI scripts that can be used to run a local instance of Elasticsearch in a container, as well as run the tests in a container:
when spinning up elasticsearch with run-elasticsearch.ps1, an environment variable is set, allowing cargo test to run against the instance easily
RUST_BACKTRACE can be passed to the test container for more verbose error messages
This PR adds the ability to configure certificate validation in different ways, for the SSL/TLS certificates used to establish a HTTPS connection.
When using self-signed certificates, it's a common feature to provide the ability to determine how a certificate is validated. With this feature, four modes are provided:
CertificateValidation::Default
:This is the default validation implementation, and is essentially a no-op. It's provided simply as a means to change from a different validation mode, which is useful in testing this feature.
CertificateValidation::Full(Certificate)
:Validates that the certificate provided by the server is signed by a trusted Certificate Authority (CA) and also verifies that the server’s hostname (or IP address) matches the names identified by the CommonName (CN) or Subject Alternative Name (SAN) within the certificate. Typically, the certificate provided to the client will the Certificate Authority (CA) used to generated the certificate.
CertificateValidation::Certificate(Certificate)
:Validates that the certificate provided by the server is signed by a trusted Certificate Authority (CA), but does not perform hostname verification. Typically, the certificate provided to the client will be the Certificate Authority (CA) used to generated the certificate, and is useful for self-signed certificates that do not contain the CommonName (CN) or a Subject Alternative Name (SAN) that matches the server hostname.
CertificateValidation::None
:No validation on a provided certificate. This is intended only for development purposes and is strongly discouraged for use in production.
In https://github.com/elastic/elasticsearch-rs/commit/5afeba83936bb0a22af7464859ed3b1a2a6107d3, there are tests for the different behaviour observed when running on Windows and Linux (with the docker container used in CI). I've opened https://github.com/seanmonstar/reqwest/issues/826 to discuss.
This PR makes several enhancements to the CI scripts that can be used to run a local instance of Elasticsearch in a container, as well as run the tests in a container:
run-elasticsearch.ps1
, an environment variable is set, allowingcargo test
to run against the instance easilyRUST_BACKTRACE
can be passed to the test container for more verbose error messagesCloses #55