SSL with SSL for Free verification now via CNAME

[AGTDenton 2]

Based on the following guide, it says to verify the certificate via TXT.

https://emby.media/support/articles/Secure-Your-Server.html

SSL For Free does not allow me to do that anymore, and my verification options are Email, CNAME or HTTP File Upload.

I've given the CNAME option a go, but with no success whatsoever.

Based on the fact I'm using Dynu, Email & HTTP File Uploads are not possible.

 

Could the guide be updated to be compatible with the latest options from SSL for Free? or is Emby only compatible with TXT and I need to do another method?

 

Many Thanks

[Abobader 3464]

Hello AGTDenton,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 42080]

Hi, what exactly is the problem?

[MBSki 1114]

27 minutes ago, Luke said:

Hi, what exactly is the problem?

The problem is that the guide is wrong and needs to be updated to match the changes made within the recommended services.

[pwhodges 2012]

@LukeI have verified that this change in the verification procedure has been made - this image shows the DNS verification process as of today (but this cannot work - see note below):

This change must be very recent indeed, as all their example videos still show the TXT method in use!

The OP reported that they failed with this CNAME method.  Actually, I can see the reason immediately - FreeSSL's test CNAME starts with an underscore, which is not a valid character in a domain name!  So this method will not work with any registrar which does a proper check on the names, and many DNS forwarders may also block it from working.  Well done FreeSSL - you messed up royally!

Paul

 

[pwhodges 2012]

2 hours ago, MBSki said:

The problem is that the guide is wrong and needs to be updated to match the changes made within the recommended services.

Another problem is that this method cannot work as implemented (see above post)...

Paul

[Luke 42080]

OK @Carlocan take a look at updating this. Thanks.

[Q-Droid 989]

A CNAME is not a domain record and many DNS providers support the leading underscore for this record type as for TXT as well and those who don't probably should. 

The OP's provider is Dynu which does support the underscore character at the beginning of a CNAME record. It should be a viable option for their renewal. If it's not working then FreeSSL might have indeed screwed the pooch but in some other way.

 

Edited August 24, 2023 by Q-Droid

[pwhodges 2012]

9 hours ago, Q-Droid said:

A CNAME is not a domain record and many DNS providers support the leading underscore for this record type as for TXT as well and those who don't probably should. 

The OP's provider is Dynu which does support the underscore character at the beginning of a CNAME record. It should be a viable option for their renewal. If it's not working then FreeSSL might have indeed screwed the pooch but in some other way.

I tested this for myself, and for me also the process failed.

My domain registrar's DNS server (Gandi.net) did indeed allow me to create the required entry (I'm not sure why you say an entry in a domain server is not a domain record).  However, I was unable to resolve it through my ISP's DNS server (Zen.co.uk - a highly rated UK ISP), even just using nslookup - hence my remark about it possibly being blocked by some resolvers.

In fact, the earlier somewhat common (though already forbidden by RFC 1035) use of underscores in domain names was officially deprecated for use in certificates in particular back in 2018: details here.  Given the very unofficial support for underscores, their use in the validation context seems highly unfortunate (and with me and the OP has led to two failures out of two).

EDIT:

I see that there is a distinction made between "domain name" and "host name", with the host name being more restricted in form.  However, I also see a background of failures of systems relying on the use of underscores...  Like so much of the Internet, this is actually a bit of a mess.

Paul

Edited August 25, 2023 by pwhodges

[Q-Droid 989]

Not all DNS records specify a domain. Yes, a CNAME is a DNS record to define an alias for a canonical name but not a domain record.

I use Dynu for my DDNS and have created and tested a CNAME record with a leading underscore for which all public resolvers I tested responded with the correct answer for the IP and canonical name. I tried the Zen DNS servers but they're don't seem to be public.

It depends on the DNS service interface but when creating the CNAME you often define just the node name which is then prepended to the domain/subdomain, the canonical name is a fully qualified entry. Entering the full <nodename>.<domain> can result in <nodename>.<domain>.<domain> but this depends on the service and dashboard UI.

The reason I brought this up was in case the KB article is updated that it doesn't exclude verification options that do indeed work but maybe not for all service providers. Perhaps I should test getting a cert from FreeSSL using Dynu for verification.

Edit: FreeSSL or SSL for Free? or both?

 

Edited August 25, 2023 by Q-Droid

[pwhodges 2012]

SSL for Free - FreeSSL was a typo.

Paul

[Q-Droid 989]

I was able to get a cert from SSL for Free using their CNAME verification for a Dynu DDNS domain, issuer is ZeroSSL.

One thing I couldn't do was verify the CNAME record using nslookup though it did work with dig and the response matched the given canonical name.

Edit: regarding nslookup, I was using the wrong query option and the parameter -type=cname (or -q=cname) does resolve for the CNAME check if you want to verify the DNS change before domain verification for the cert.

 

Edited August 25, 2023 by Q-Droid

[AGTDenton 2]

1 hour ago, Q-Droid said:

I was able to get a cert from SSL for Free using their CNAME verification for a Dynu DDNS domain, issuer is ZeroSSL.

One thing I couldn't do was verify the CNAME record using nslookup though it did work with dig and the response matched the given canonical name.

Edit: regarding nslookup, I was using the wrong query option and the parameter -type=cname (or -q=cname) does resolve for the CNAME check if you want to verify the DNS change before domain verification for the cert.

 

When you did the CNAME verification for your cert, which way round should Name & Point To be placed into Dynu's Node Name & Hostname?

I have tried both ways, but perhaps only one field is supposed to be populated.

Many thanks

[Q-Droid 989]

Using the image posted above by @pwhodges as an example and assuming your domain is agtdenton.dynu.net:

- Go to Control Panel -> DDNS Services -> your domain -> DNS Records.

- Select record type CNAME.

- Enter the Name given by SSL for Free into the Node Name field but only the leading portion, not the fully qualified name. This is the prefix added to your domain when you save and will look like <name>.agtdenton.dynu.net on the record list.

- Enter the Point To name given into the Hostname field as is, fully qualified.

- TTL doesn't really matter and 120 default is fine.

After you save you should be able to run a check with nslookup -type=cname <name>.agtdenton.dynu.net. You should get an answer with your alias and the canonical name (point to) but no IP resolved. If it works you can click on the Next Step to have your cert issued.

 

[AGTDenton 2]

2 hours ago, Q-Droid said:

Using the image posted above by @pwhodges as an example and assuming your domain is agtdenton.dynu.net:

- Go to Control Panel -> DDNS Services -> your domain -> DNS Records.

- Select record type CNAME.

- Enter the Name given by SSL for Free into the Node Name field but only the leading portion, not the fully qualified name. This is the prefix added to your domain when you save and will look like <name>.agtdenton.dynu.net on the record list.

- Enter the Point To name given into the Hostname field as is, fully qualified.

- TTL doesn't really matter and 120 default is fine.

After you save you should be able to run a check with nslookup -type=cname <name>.agtdenton.dynu.net. You should get an answer with your alias and the canonical name (point to) but no IP resolved. If it works you can click on the Next Step to have your cert issued.

 

Thanks so much, got it working!
Not including the fully qualified name is vital information here! To someone that doesn't understand SSL/Domain things it's not something I would have spotted in a million years.

 

Regarding the documentation, I should also point out that since it was written the location for adding the SSL  certificate in Emby Settings has changed as well. Currently the guide points you to Dashboard > Advanced, when it's now Server > Network

In all honesty I would recommend starting again with that tutorial. I'd be quite happy in writing a new guide, if it helps.

Cheers everyone!

Edited August 25, 2023 by AGTDenton