3

I'm using letsencrypt in two ways: a docker stack using certbot, and another using traefik (which performs certificate management automatically, using lego). In both cases there's a setting for the registration email address.

Is that email address stored in the certificate, or elsewhere? And can anyone (other than letsencypt) discover that email address?

lonix
  • 1,119

2 Answers2

4

(edited to clarify the response)

As detailed in the post above, the email address associated with LetsEncrypt created certificates do not encode the email in the certificate itself, and it is not possible to achieve this.

I misinterpreted the original post and I also mistakenly thought that LetsEncrypt was providing fuller X.509 v3 compliance. I've found that RFC 8555 which defines the ACME protocol that LetsEncrypt uses to extend RFC 5280 only (currently) allows the "dns" identifier. This means their implementation would not allow an email address in an X.509 v3 field thus would prevent it from ever being encoded into a certificate.

When creating a certificate using OpenSSL or another X.509 v3 compliant tool, it is a possible option to encode an email address into the certificate within the subject alternative name field.

From: https://www.rfc-editor.org/rfc/rfc5280

4.2.1.6. Subject Alternative Name

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4. Note that where such names > are represented in the subject field implementations are not required to convert them into DNS names.

The ACME protocol is the underlying standard that LetsEncrypt uses for certificate issuance and management. It was developed to automate and simplify the issuance and domain validation process in order to make a once manual process streamlined and not require any human interaction (It has been successful - https://www.abetterinternet.org/documents/2023-ISRG-Annual-Report.pdf). While this builds on top of the X.509 v3 standard described in RFC5280 (and others), it only narrowly implements certain specifications and extensions to reach their goal.

The Internet Security Research Group had a goal in 2013 of rapidly increasing the adoption of https encrypted pages and to accomplish that goal, they built LetsEncrypt, which is a certificate authority (CA) specifically implemented to enable the automatic issuing of certificates as well as validating them without human involvement. In 2015, they began automatically issuing certificates using LetsEncrypt.

Their focused implementation did not fully support the types of identities permitted as described in the "Subject Alternative Name" certificate extension section in RFC 5280.

From: https://www.rfc-editor.org/rfc/rfc5280

4.2.1.6. Subject Alternative Name

The subject alternative name extension allows identities to be bound > to the subject of the certificate. These identities may be included > in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included.

This is detailed in RFC 8555, "Automatic Certificate Management Environment (ACME)" which states the following:

From: https://datatracker.ietf.org/doc/html/rfc8555

7.1.4. Authorization Objects

...

The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").

Thus, the top answer is the most correct one, yet I hope this answer was able to provide some background and RFC reference detail to describe the "why" and "how".

Colin Hines
  • 41
3

From the letsencrypt forum:

  • The only ones who know that (very powerful) email address are you, and Let's Encrypt
  • It's used by Let's Encrypt to inform you of a pending expiration
  • It won't be encoded into the certificate
  • It won't be published anywhere, and so won't be contained in any "transparency logs" service

And:

The correlation of email to account/domains only exists in two places:

  • LetsEncrypt's database, which associates an Email Address to an Account ID. LetsEncrypt staff can pull this info themselves. You can pull this info yourself by presenting LetsEncrypt with the current AccountKey, which happens under secure https connections. No third party can access this information from LetsEncrypt. Intercepting this information during an API call would require a MITM or other attack.
  • If LetsEncrypt sends an expiry email, that email may be relayed to you by trusted third parties. It is possible, but incredibly unlikely, that (i) LetsEncrypt's email service providers or (ii) your email service provider, are mining this information from the emails they relay and store.
lonix
  • 1,119