aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKim Alvefur <zash@zash.se>2021-02-06 22:12:38 +0100
committerKim Alvefur <zash@zash.se>2021-02-06 22:12:38 +0100
commit3fd016e66a925b04d764d0e00c2fcb9a48a37629 (patch)
treea9fb9ef0caba7582153f1f4ee643ee7dd9127b23
parentcd1aadb52e228915a10a37c8de35d539ba5ad8fb (diff)
downloadprosody-3fd016e66a925b04d764d0e00c2fcb9a48a37629.tar.gz
prosody-3fd016e66a925b04d764d0e00c2fcb9a48a37629.zip
core.certmanager: Add comments explaining the 'verifyext' TLS settings
Thanks to debacle for reminding me, in the context of mod_auth_ccert I wonder if we still need lsec_ignore_purpose, Let's Encrypt seems to include both client and server purposes in certs.
-rw-r--r--core/certmanager.lua5
1 files changed, 4 insertions, 1 deletions
diff --git a/core/certmanager.lua b/core/certmanager.lua
index 023218fa..4bc98935 100644
--- a/core/certmanager.lua
+++ b/core/certmanager.lua
@@ -118,7 +118,10 @@ local core_defaults = {
single_dh_use = luasec_has.options.single_dh_use;
single_ecdh_use = luasec_has.options.single_ecdh_use;
};
- verifyext = { "lsec_continue", "lsec_ignore_purpose" };
+ verifyext = {
+ "lsec_continue", -- Continue past certificate verification errors
+ "lsec_ignore_purpose", -- Validate client certificates as if they were server certificates
+ };
curve = luasec_has.algorithms.ec and not luasec_has.capabilities.curves_list and "secp384r1";
curveslist = {
"X25519",