Data processing agreement

My domain is:

I ran this command: n/a

It produced this output: n/a

My web server is (include version): n/a

The operating system my web server runs on is (include version): n/a

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don’t know): n/a

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): n/a

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): n/a

Hi, I tried searching this topic, but couldn’t find anything.

Whenever a user visits a site with a Let’s Encrypt certificate, some of their personal information (including IP address) is transfered to Let’s Encrypt.

Does this not make Let’s Encrypt a data processor under GDPR? Do I, as the site owner, need a data processing agreement with Let’s Encrypt? I could find nothing in the terms or privacy policy.

Thanks in advance.

Hi @kleingeld

which "personal informations"?

Letsencrypt uses OCSP:

But I don't see this is GDPR relevant.

1 Like

The IP address is personal data under GDPR (not that I agree with that, but it’s a fact). Let’s Encrypt processes the user’s IP, so GDPR applies whenever it’s a EU user or website.

That's technical wrong. If a user visits a site with a Letsencrypt certificate and if that webserver doesn't use OCSP stapling, then the browser connects Letsencrypt. So it's user-initiated.

The user can stop that (in FireFox), if I know it correct, Chrome ignores OCSP.

So it's only an additional connect to a website.

But: Ask a lawyer, I'm not one.


Even OSCP stapling connects to a "trusted third party" server for verification.
REF: Online Certificate Status Protocol - Wikipedia

As @JuergenAuer suggests,


Yes, but with stapling only the web server connects to the OCSP server. It then caches the response and serves it directly to clients. So with OCSP stapling there's no reason for the user's client to ever connect to Let's Encrypt's servers.

Edit: note that you shouldn't rely on this. If OCSP stapling fails (i.e. connection failure, DNS timeout) then your server might just not send a stapled response, and the client could do its own lookup. So you shouldn't assume that enabling OCSP = no client will ever do its own OCSP lookup. Stapling is primarily an optimization to reduce latency for clients that do revocation checking.

I think it’s already (partly) answered here: European GDPR and personal data processing


The current part of the LE privacy policy dealing with OCSP is the "Relying Party" section

When you use an HTTPS web site or other TLS service with a Let’s Encrypt certificate, your browser (or TLS client) may query Let’s Encrypt to check whether the certificate has been revoked (“OCSP request”). If your browser makes an OCSP request, our servers will automatically record your IP address, browser, and operating system in temporary server log files. We do not use data from OCSP requests to build profiles or identify individuals. Temporary server logs are used for operational purposes only and are normally deleted in less than seven days. We may retain a subset of server logs for longer periods in order to investigate software failures or abuse. If we do so, we will delete any stored logs when we are done investigating. We may also compute, retain and publish aggregate information from server logs, such as which certificates generate the largest volume of requests. We will always strive to ensure that such datasets do not contain information about the activities of identifiable users or devices.


...and this part is pretty important. @kleingeld, if you configure your server to use OCSP stapling, there's no reason any of your users would be sending OCSP status queries--because you'd be providing them along with the cert.


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