From: Joe Orton
MDActivationDelay
MDBaseServer
MDCACertificateFile
MDCAChallenges
MDCertificateAgreement
MDCertificateAuthority
MDDriveMode
MDExternalAccountBinding
MDHttpProxy
MDInitialDelay
MDMatchNames
MDMember
MDMembers
| Description: | File containing x509 trust anchors to verify ACME servers. |
|---|---|
| Syntax: | MDCACertificateFile file |
| Default: | MDCACertificateFile none |
| Context: | server config |
| Status: | Experimental |
| Module: | mod_md |
+ This is mainly used in test setups where the module needs to + connect to a test ACME server that has its own root certificate. + People who run an enterprise wide internal CA can use this when + they run their own ACME servers. +
++ Use "none" as path to disable explicitly. +
+| Description: | How long to delay the first certificate check. |
|---|---|
| Syntax: | MDInitialDelay duration |
| Default: | MDInitialDelay 0s |
| Context: | server config |
| Status: | Experimental |
| Module: | mod_md |
| Compatibility: | Available in version 2.4.66 and later |
+ The amount of time to wait after the server start to check + renewals of certificates. By default this occurs right away. +
+This directive sets policy applied when checking whether the +
This directive sets the policy applied when checking whether the
<VirtualHost>
identified by the Host request header in an HTTP request
is compatible with the <VirtualHost> identified from the SNI
@@ -3055,6 +3055,12 @@ request is associated with a virtual host which has an incompatible
SSL/TLS configuration under the policy used, an HTTP error response
with status code 421 ("Misdirected Request") will be sent.
The policy also applies to TLS connections where an SNI extension +is not sent during the handshake, implicitly using the default or +first virtual host definition. If the Host header in an HTTP request +on such a connection identifies any other non-default virtual host, +the compatibility policy is tested.
+The strict policy blocks all HTTP requests which are
identified with a different virtual host to that identifed by SNI.
The insecure policy allows all HTTP requests regardless
@@ -3064,43 +3070,43 @@ of virtual host identified; such a configuration may be vulnerable to
The (default) secure, and authonly
policies compare specific aspects of the SSL configuration for the two
-virtual hosts, which are grouped into two categories:
+virtual hosts, which are grouped into two categories:
SSLVerifyClient, SSLVerifyMode, SSLCACertificatePath, SSLSRPVerifierFile; any use of SSLOpenSSLConfCmdSSLCertificateKeyFile etc), cipher or
protocol restrictions (SSLCipherSuite and SSLProtocol)SSLVerifyClient, SSLVerifyMode, SSLCACertificatePath, SSLSRPVerifierFile; any use of SSLOpenSSLConfCmdThis table illustrates whether an HTTP request will be blocked or allowed when the virtual host configurations differ as described, -under each different policy setting: +under each different policy setting:
| Policy mode | Any VirtualHost mismatch | -Client verification/ authentication settings |
Server certificate/key, or protocol/cipher restrictions |
+ Client verification/ authentication settings |
|||
|---|---|---|---|---|---|---|---|
strict | blocked | blocked | blocked | +strict | blocked | blocked | blocked |
secure | allowed | blocked | blocked | +secure | allowed | blocked | blocked |
authonly | allowed | blocked | allowed | +authonly | allowed | allowed | blocked |
insecure | allowed | allowed | allowed | +insecure | allowed | allowed | allowed |
SSLVHostSNIPolicy authonly