https://❤.rust-lang.org has an invalid SSL cert

[luser]

I was looking at a Rust release blog post, and it mentioned thanks.rust-lang.org, and also mentioned that it existed at https://❤.rust-lang.org . However, visiting the site from that URL doesn't work because the SSL cert it serves only mentions thanks.rust-lang.org as the CN.

In the Let's Encrypt forums I found this post, which suggests that you can ask it to generate a cert containing multiple domains. I don't know what process you're using to generate the certs, but that may be a workable solution.

[steveklabnik]

@alexcrichton you recently changed this, I think?

[alexcrichton]

We're using Heroku's Let's Encrypt feature here for SSL, and it looks like it may not work with unicode domain names? I've reconfigured for like the 4th time just to confirm and it just indicates that this domain is failing to get an SSL cert :(

[luser]

Let's Encrypt says they support IDN, and this forum post says it should work with the punycode, but it also mentions that certbot 0.9.2 prevents IDN from working, so it's possible that Heroku just isn't using up-to-date client libraries that allow this.

[alexcrichton]

I've created a help ticket with heroku: https://help.heroku.com/tickets/479405

I think that's a private link in terms of you need to be logged in, but hopefully that way I won't forget it!

[alexcrichton]

Their response

---

Hi Alex,

Sorry for the delay in getting back to you. When first approaching this issue I was delayed by the Let's Encrypt/ACM outage that existed for all of the US business day on Friday. Only after they resolved that issue did I discover it wasn't a Let's Encrypt issue.

This is a bug in the DNS (IDN-capable) Go library we use. We've previously fixed issues with punycode/IDN domains in ACM, but converting your ❤.rust-lang.org domain returns an empty string. The engineer who helped me debug this issue has already opened up an issue about it on the upstream repo ( miekg/dns#490 ). We're going to see if we can get this issue fixed on our own and contribute it back upstream, but I wanted to follow up with you thus far and let you know that we do understand why this is happening.

I'm leaving this ticket open and will provide updates for you as we have them. If you require this domain to be SSL protected, you'll either need to engage Let's Encrypt directly for now, or obtain a paid certificate from a punycode-supporting SSL Certificate Authority in the meantime.

Let me know if you have any other questions.

Thanks!
Jason

[RBeaudoin]

@luser @alexcrichton I'm an engineer at Heroku and working on this issue. Our Automated Certificate Management (ACM feature) does indeed work with unicode. Unfortunately it turns out that code point 10084 (U+2764 - ❤) (which is being used in " https://❤.rust-lang.org") is disallowed per https://tools.ietf.org/html/rfc5892#appendix-B.1.

Our testing shows it works in some idn/punycode libraries/tools, but not in others due to the code point being disallowed.

Let me know how we can work with you to address this, we love hosting your content 😄

[steveklabnik]

I am confused about this given that it was previously working; something else was not following that RFC, I guess?

[RBeaudoin]

@steveklabnik it seems that this is a controversial code point in terms of idn/libraries allowing/disallowing it. We've found it works in some tools, and not in others, but the RFC we've been pointed to has:

2761..2794  ; DISALLOWED  # CURVED STEM PARAGRAPH SIGN ORNAMENT..HEAVY W

And the library we use is enforcing the RFC. I would imagine that the implementation you were previously using was more lenient in terms of the RFC.