summaryrefslogtreecommitdiffstats
path: root/docs/reference/plugins/validation/tls-alpn/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/reference/plugins/validation/tls-alpn/index.md')
-rw-r--r--docs/reference/plugins/validation/tls-alpn/index.md18
1 files changed, 0 insertions, 18 deletions
diff --git a/docs/reference/plugins/validation/tls-alpn/index.md b/docs/reference/plugins/validation/tls-alpn/index.md
deleted file mode 100644
index d1b6aa9..0000000
--- a/docs/reference/plugins/validation/tls-alpn/index.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-sidebar: reference
----
-
-# TLS-ALPN validation
-TLS-ALPN validation works as follows:
-- For each domain (e.g. `sub.example.com`), the ACME server sends a
-challenge consisting of an `x` and `y` value. The truth is actually a little
-more complicated than that, but for the sake of this explanation it will suffice.
-- The client has to make sure that when the ACME server sets up a TLS connection
-to `sub.example.com`, a specifically crafted negotiation response with a
-self-signed certificate containing the `y` value as extension is presented.
-- The validation request is *always* made to port 443, that cannot be changed.
-- There may be more than one validation connection for the same token, e.g.
-for different IP addresses (in case of multiple A/AAAA records).
-- Let's Encrypt does **not** disclose the source locations of these requests, which
-effectively means that the domain has to be accessible for the public,
-at least for the duration of the validation. \ No newline at end of file