Hi Archie, Archie Halliwell writes: > On 14/2/25 19:34, Eli Zaretskii wrote: >>> Date: Fri, 14 Feb 2025 14:43:32 +1100 >>> From: Archie Halliwell >>> >>> The ERC Manual does not explain how to use .pem client certificates, >>> only how to use the combination of a .crt certificate and .key private >>> key. This is confusing as Libera.Chat's CertFP instructions only mention >>> the use of a .pem file, instructing users on how to create an >>> appropriate one. >>> >>> The manual should really mention that a .pem file can be used as both >>> files in the client-certificate list. >> Does ERC use the .pem file directly, or does it use it indirectly, >> though some GnuTLS interface? If the latter, then the source might >> not be from a .pem file, but instead from some equivalent OS service >> (this happens on MS-Windows, for example). So the manual should not >> cause users of such systems go look for a .pem file that might not >> even exist, or be irrelevant. >> >> Apologies if the above makes no sense: I don't use ERC and know very >> little about it. >> >> Thanks. > I believe that ERC uses GnuTLS, however the filenames are either specified in > the client-certificate argument to ,,erc-tls,, or found in .authinfo.gpg. The > manual gives examples using .key and .crt files, but not using .pem files. > There is mention of using other services to provide certificates using > auth-service, however auth-service seems to have disappeared and all links to > it are broken. Libera.Chat's instructions mention the creation of .pem files > on Windows as well, so I expect that specifing a .pem file through the > client-certificate keyword argument is the "correct" way on all platforms. ERC supposedly relies on a generalized underlying transport to provide a network process for exchanging IRC protocol messages with a server. In practice, it's only equipped to handle TCP streams and defers to an `open-network-stream'-compatible "opener" to create the necessary goods. The opener for TLS encrypted streams is `erc-open-tls-stream', a thin wrapper around `open-network-stream'. In this case, ERC passes the :client-certificate from `erc-tls' directly to `open-network-stream', which ultimately relies on `network-stream-certificate' to transform it into something suitable for the :keylist parameter of `gnutls-boot'. FWIW, the doc string of `gnutls-boot' does mention that :keylist is an alist of PEM-encoded key files and PEM-encoded certificates for ‘gnutls-x509pki’ which comports with its calling gnutls_certificate_set_x509_key_file2 and friends with a hard-coded GNUTLS_X509_FMT_PEM, although there's a friendly note saying /* TODO: GNUTLS_X509_FMT_DER is also an option. */ In any case, this info is likely one too many clicks removed from ERC's docs. So, I think it makes sense for us to mention the format must be PEM and that the key and the cert can be the same concatenated file. In terms of file-name extensions, it's true that the examples on Libera's site (and OFTC's) all appear to be .pem. OpenSSL's man pages use .pem when contrasting it with .der, although the format is typically declared explicitly with options like -outform. The .key and .crt extensions in ERC's manual may originate from the docs of other IRC clients or from the world of domain-name validation. Either way, I agree we should probably change them all to .pem. As for the broken auth-source hyperlinks, I'm not sure they're fixable on ERC's side (ditto for all other non-ERC links). FWIW, they should only be broken on https://elpa.gnu.org/packages/doc/erc.html. The ones on https://www.gnu.org/software/emacs/manual/html_mono/erc.html and in the Info manual (info "(erc) client-certificate") should work fine. Anyway, the attached patch includes the mentioned changes, which are mostly mechanical in nature. Please give feedback if you can. Thanks, J.P.