[Client Authentication] `emailAddress` is not present

1. Caddy version:


2. How I installed, and run Caddy:

with docker

a. System environment:

b. Command:

docker compose build --pull --no-cache
docker compose up --detach

c. Service/unit/compose file:

# Build Caddy with the Mercure and Vulcain modules
FROM caddy:2.6-builder-alpine AS app_caddy_builder

RUN xcaddy build \
	--with github.com/dunglas/mercure \
	--with github.com/dunglas/mercure/caddy \
	--with github.com/dunglas/vulcain \
	--with github.com/dunglas/vulcain/caddy

# Caddy image
FROM caddy:2.6-alpine AS app_caddy
RUN apk add --no-cache \
		nss-tools \

WORKDIR /srv/app

COPY --from=app_caddy_builder --link /usr/bin/caddy /usr/bin/caddy
COPY --from=app_php --link /srv/app/public public/
COPY --link docker/caddy/Caddyfile /etc/caddy/Caddyfile

d. My complete Caddy config:

	# Debug


	tls {
		client_auth {
			mode require_and_verify
			trusted_ca_cert_file /etc/caddy/certs/ca.pem


	route {
		root * /srv/app/public
		mercure {
			# Transport to use (default to Bolt)
			transport_url {$MERCURE_TRANSPORT_URL:bolt:///data/mercure.db}
			# Publisher JWT key
			# Subscriber JWT key
			# Allow anonymous subscribers (double-check that it's what you want)
			# Enable the subscription API (double-check that it's what you want)
			# Extra directives
		php_fastcgi unix//var/run/php/php-fpm.sock {
            env SSL_CLIENT_S_FINGERPRINT {http.request.tls.client.fingerprint}
            env SSL_CLIENT_S_CERTIFICATE {http.request.tls.client.certificate_der_base64}
            env SSL_CLIENT_S_ISSUER {http.request.tls.client.issuer}
            env SSL_CLIENT_S_SERIAL {http.request.tls.client.serial}
            env SSL_CLIENT_S_DN {http.request.tls.client.subject}
		encode zstd gzip

3. The problem I’m having:

The client authentication works fine. The CA certificate chain is correctly loaded on server side and, with a valid client certificate, I am able to see the environment variables sent to the PHP application by Caddy.

However, I noted the value of the placeholder http.request.tls.client.subject is not formatted as it should be (or at least as formatted by other applications such as NGNIX or Apache).
As an example, the result I have is as follows:


The emailAddress field is missing, but its OID 1.2.840.113549.1.9.1 is present. The value #0c126a6f686e2e646f65406d6574656f666f6e79 is the actual email address I expect (john.doe@meteofony)

I expect the subject string to be:


4. Error messages and/or full log output:

No error messages

5. What I already tried:

I am not sure how to modify the subject placeholder

6. Links to relevant resources:

Nothing to share

Ooh, bonjour Florent! Je viens de réaliser que j’ai manqué ta conférence à API-P conf :frowning: J’ai resté dans la track anglaise, après avoir donné la mienne. Je reconnais ton nom de tes lib de PHP que j’utilise depuis plusieurs années. Je travaillait avec FIDO U2F, à une compagnie qui vendait une clé USB, j’étais très intime avec le protocol à ce temps là. J’ai changé d’emploi avant d’avoir la chance de travailler sur v2 avec CBOR etc, mais ton implémentation avait l’air très bonne :slight_smile:

But I digress… :joy:

We use the Go stdlib tooling for TLS cert decoding. I suppose that’s an issue there. First I’m hearing of it though.

It looks like the pkix.Name struct doesn’t have an EmailAddress field, which means that it gets put in the ExtraNames field instead, I think, and those get encoded with the OID + hex bytes.

It looks like CloudFlare merged a patch to their own fork of Go to add this functionality:

It seems like the emailAddress field is considered deprecated as per RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, hence why Go doesn’t handle it.

Are you sure you still need emailAddress? Could you do without it?

I’m not sure I have a better answer for you, because I don’t think we should implement a hack in Caddy to work around this since it’s a deprecated field. Could you perform the replacement in PHP? It should be pretty trivial to do.


Hi Francis,

Thank you for the very quick answer.

But I digress… :joy:

I will be happy to continue the digression with DM. I am sure sure feedback will help me for these side projects.

I was not aware of the RFC5280 and the fact that emailAddress is now deprecated. Also I concur with you and I do not see any reason for implementing here something that is going to be removed in a near futur.

Are you sure you still need emailAddress ? Could you do without it?

Actually, yes I can do without it.
The PHP application behind this is a Symfony app. With Symfony 6.2 and lower, it is not possible to use something else than emailAddress. But hopefully, for another reason, I opened a PR that is now merged and will be available in Symfony 6.3 for everyone. This is not a problem for me at all and other developper just have to wait for the official release in May 2023.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.