Email contact on Let's Encrypt SSL/TLS certificates uses Password Recovery email rather than Primary email address

[d19dotca]

Hello,

I just realized the Password Recovery email on my profile is what appears to be used in the email contact on the certificates that Cloudron retrieves from Let's Encrypt. Unfortunately in my case my recovery email is my employer's email rather than my own.

I suppose I can fix this by changing my password recovery email to match my actual email but it's hosted on Cloudron so if I ever had a password issue I'd lose access.

This seems like a defect. Can anyone please confirm? Maybe I'm doing something wrong?

[girish]

@d19dotca Right, we pick the recovery email over the primary email - https://git.cloudron.io/cloudron/box/-/blob/master/src/reverseproxy.js#L82 . I have to think a bit more as to why the code is this way.

[d19dotca]

@girish Ah okay, perfect, yeah I think that should be changed to just the primary email address, or maybe break it out to be it's own option/field in the configuration of Cloudron by an admin user. I guess in the meantime the workaround is for me to change that Password Recovery email address temporarily, delete all certs, renew them so they use the new email, then set the Password recovery email address back again.

[girish]

@d19dotca Where are you seeing the contact information of a certificate? Atleast, I cannot see it in firefox or chrome when trying to inspect the certificate.

[d19dotca]

@girish I just saw my email provided by my employer used in the logs for contact information. So I suppose the good news is this isn't exposed externally, but it still means any messages from Let's Encrypt will go to my work email and not the email I want it to go to.

My statement in the original post was incorrect then I just realized as I sort of wrote it in a way that meant the email was exposed on the certificate and it is not actually on the certificate. Updated statement for clarification: The email address used by Cloudron on certificates is not actually on the certificate, in other words it is not external facing information. However, I believe it is used by Let's Encrypt for communication so internally it may not be the right email that's desired for communication with Let's Encrypt.

[girish]

Ah right. So, Let's Encrypt has a notion of "account". This 'account' has your work email id. AFAIK, they use this email to send renewal notifications (like cert is expiring etc and other API changes) but it's not used in the cert itself.

[d19dotca]

@girish Correct. I updated my comment earlier, I think we published at the same time. haha. That needs to be fixed though still, as it is not expected behaviour. For example, I would not expect Cloudron to use my Password Recovery email address for anything other than recovering my password. It should use the primary email address for everything else.

[girish]

@d19dotca Ha ha, yes. I think it's safe to fix the code to use the primary email.

IIRC, this comes from the fact that back in the day we used to have a 1-1 mapping between primary email and the domain. So a user girish would get primary email automatically as girish@cloudrondomain. In such a case, let's encrypt cannot use this email address until the user has setup MX records. This is because Let's encrypt requires the email address to be a valid address. So, we decided to use the fallback address because that was guaranteed to be a valid one.

I guess we don't have this problem today because we don't automatically set primary email to be something hosted on Cloudron.

[girish]

OK, I have fixed this for the next release. Thanks for reporting!

[d19dotca]

@girish I'm always amazed at how quick you guys on these things, thanks for fixing that so soon!