I received a notification for a Let’s Encrypt issued certificate for my domain name (murdoch.is), but I’m not sure why this has been issued. Is there any way to find out more information about what has happened?
Well… Someone either (momentarily) uploaded a file to http://murdoch.is/.well-known/acme-challenge/, or put a certificate on https://murdoch.is/, or created a TXT record at _acme-challenge.murdoch.is. Or compromised BGP, DNS or (goddess forbid) Let’s Encrypt to make it seem like they did.
I take it you’re sure it wasn’t you.
Are you sure your hosting company didn’t think it was a swell idea for some reason?
Let’s Encrypt has records – in particular, the IP addresses involved – but I’m not sure what the process is for disclosing them. After all, anyone could wait until you issue a legitimate certificate, then make a fake forum account with your name. 
1 Like
Maybe FastMail is rolling out automatic Let’s Encrypt integration for their customers?
1 Like
Thanks. I have asked Fastmail on Twitter but Australia is asleep at the moment. It would be great if they rolled out Let’s Encrypt integration, but a bit naughty to do it without asking first.
I don’t think it was me, and can’t see anything in the 1984.is DNS control panel or Fastmail settings that would allow anyone to take the actions that you indicate.
I’m in the process of revoking the certificate now, but would like to understand what happened.
Certificate is now revoked (validated through DNS). Thanks for having clear instructions here!
I’m now suspecting it is Fastmail doing something funny. I have set up my Fastmail account to re-direct murdoch.is to another URL via HTTP 302, which seems to work fine
$ wget -S -O /dev/null http://murdoch.is/blah
--2017-12-20 18:06:59-- http://murdoch.is/blah
Resolving murdoch.is (murdoch.is)... 66.111.4.54, 66.111.4.53
Connecting to murdoch.is (murdoch.is)|66.111.4.54|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
Server: nginx
Date: Wed, 20 Dec 2017 18:06:59 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 290
Connection: keep-alive
X-Request-Id: web5-301604-1513793219-78
X-Backend: web5
X-Request-Id: web5-301604-1513793219-79
Location: http://sec.cs.ucl.ac.uk/users/smurdoch//blah
X-Frontend: frontend2
Location: http://sec.cs.ucl.ac.uk/users/smurdoch//blah [following]
However, if I request the ACME directory, I don’t get the re-direct. Maybe they are injecting their verification credentials here?
$ wget -S -O /dev/null http://murdoch.is/.well-known/acme-challenge/
--2017-12-20 18:08:31-- http://murdoch.is/.well-known/acme-challenge/
Resolving murdoch.is (murdoch.is)... 66.111.4.54, 66.111.4.53
Connecting to murdoch.is (murdoch.is)|66.111.4.54|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 404 Not Found
Server: nginx
Date: Wed, 20 Dec 2017 18:08:31 GMT
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
X-Request-Id: web5-302270-1513793311-76
Content-Encoding: gzip
2 Likes
From our side there is nothing to indicate this was an unauthorized domain validation request. The ACME client UserAgent was from FastMail so I think this was your hosting provider acting on your behalf as you suspect. The same UA/IP has issued for a number of other names today.
Hopefully FastMail is able to provide more context. One immediate step that you could take is to add a CAA record to the DNS zone for murdoch.is that does not include Let's Encrypt - this will block anyone from using Let's Encrypt to issue for your domain name. Something like:
murdoch.is. IN CAA 0 issue ";"
1 Like
Good catch. 
That's quite likely. They must have had some reason to special case that directory, after all.
Did you know there’s a second certificate?
15:05 UTC https://crt.sh/?id=283182967&opt=ocsp (revoked)
17:52 UTC https://crt.sh/?id=283267218&opt=ocsp (not revoked)
Did you create that certificate while revoking, or did FastMail get a second one?
1 Like
@mnordhoff Yes, the second certificate is mine, which is created as a side-effect of the instructions on how to revoke a certificate.
$ sudo openssl x509 -fingerprint -sha256 -inform pem -in /etc/letsencrypt/live/murdoch.is/cert.pem -noout
SHA256 Fingerprint=17:AA:A9:1A:EF:19:EB:2D:88:05:22:D8:C6:BA:B1:8E:2F:F1:CD:BC:87:44:AE:5D:8E:30:2A:0B:9F:5F:FB:58
Thanks for pointing it out to me though. I’m not sure what I’m going to do yet, but having a certificate could be useful so I haven’t (yet) revoked it.
1 Like
Thanks @cpu, it looks indeed like Fastmail have (inadvisedly, in my opinion) requested a Let’s Encrypt certificate without informing the owner in advance. I’m pleased that they are now offering HTTPS, but going about it this way has caused unnecessary confusion. I didn’t want to be getting certificate transparency warnings while going about Christmas shopping!
(Just be be clear, I don’t think Let’s Encrypt has done anything wrong here. Fastmail are hosting the domain and so from the perspective of Let’s Encrypt are perfectly entitled to request a certificate. I’m also very happy that this domain will now have HTTPS. However, I’m not impressed by how Fastmail have managed communication around this new feature.)
2 Likes
I totally understand. I would feel similar in your situation. I’m hopeful that this feedback will be heard by FastMail and used to avoid this sort of confusion in the future so we can get back to being happy about more domains getting HTTPS (and our Christmas shopping) 
1 Like
Hi @sjmurdoch,
We’re sorry if this freaked you out! All the theories here are correct: FastMail is gearing up to provide HTTPS for all domains with site hosting. We understand, too, why you might think it’s a bad idea for us to do this without a heads-up, but we feel good about what we’re doing. This will enable instant enrollment of domains into “redirect HTTP to HTTPS,” which is where the state of hosting is moving, and we don’t expect this to cause confusion beyond… well, we were surprised even to see one person take notice! We’ll have another discussion internally about this and let you know if we change paths.
In the meantime, we’re about to add a document to our help system outlining the change, so we have something to point to if this comes up again. It’ll be up later today, and I will post a link here when it exists.
5 Likes
When you've done that, you might also want to list FastMail on
2 Likes
The help page I mentioned: https://www.fastmail.com/help/files/secure-website.html
We’ll add more to it closer to the release date (which will be announced on our blog and in customer newsletters, as we do for most new features).
2 Likes
Thanks @robn for confirming what happened, and for the new help page.
I am a little surprised at your surprise that I noticed the issuance of the certificates, given that Let’s Encrypt offers a feature (certificate transparency) that is designed precisely to notify domain name owners of certificates issued. I am therefore still disappointed by Fastmail’s lack of advance notice of what was going on. Now that this is sorted, however, I do look forward to being able to make use of this feature in due course.
As an aside, because I had to assume the first certificate for murdoch.is was issued fraudulently, I revoked it. If HTTPS goes live before the certificate expires could you please request for it to be re-issued?
1 Like
To be fair to FastMail (who are an excellent email provider), it is not exactly uncommon to automatically issue certificates on behalf of your users.
Some very large examples off the top of my head, though I am sure there are dozens/hundreds of others:
- Wix
- Cloudflare, even if you do not enrol to their proxy service
- cPanel servers
- Squarespace
If there is some kind of improvement in process that can be put in place, we should take a look at this practice more broadly rather than picking on FM 
!
1 Like
The surprise came from our thinking that anyone that knows enough about CT and LE to be actively monitoring transparency logs for their domains is almost certainly not using our web hosting, because it a) they care about HTTPS, which it doesn’t support and b) they’re probably quite technically savvy, and we’re little more than a static file sharing service.
I understand your feelings about the lack of advance notice, but given the typical profile of our customers that use file storage, and the fact that we’re doing this weeks in advance of launch so we can backfill all of them, it’s really not clear what form of notice we could give that wouldn’t just be confusing. It’s often an awkward tradeoff to make.
Regarding your domain, we will have a regular reconciliation task that tries to obtain certificates for user websites that we haven’t managed to get one for yet. murdoch.is will end up being sorted out as part of that. I’ll be reviewing our “missing” ones shortly before launch, so you’ll be considered then too!
I agree this sort of deployment is tricky, and I’m sure there are other complications I’m not aware of.
For what it’s worth, I do research in this area so am quite familiar with CT and related technologies. I use Fastmail mainly for email, but the file storage is also useful – while simple, it is easy to use and works adequately for my purposes (and its existing HTTPS support is a little awkward but functional). I could of course run my own server, but why do that when you’ll do it for me
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.