Addon Domain: Manage Subdomain(s) Only, not the Primary Domain
I have an account, my main account, let's call it Blue and it hosts blue.com on IP 1.2.3.4 (for sake of example). My friend has a domain on their own server, let's call it buddy.com (for sake of example). We want my server to handle all wildcard domains (*.buddy.com) not already being managed by buddy.com's DNS, specifically on the Blue account because that has all the software and environment on it we want to handle *.buddy.com's traffic. We also want SSL enabled.
I'm really close to figuring this out. Here's what I know I need to do:
- My friend adds DNS records for buddy.com: *.buddy.com 1.2.3.4 300 _cpanel-dcv-test-record.buddy.com ns1.blue.com 300 _acme-challenge.buddy.com ns1.blue.com 300
- I add all of buddy.com's nameserver IPs to "Configure Remote Service IPs"
- I go into the Blue cPanel account and... somehow magically (this is the part I can't figure out) only add *.buddy.com as an addon subdomain and configure it do the subdirectory I want to handle its traffic
- I install the letsencrypt plugin for AutoSSL and run it for the Blue account
-
Hey there! I think you're doing everything correctly. Since the DNS for buddy.com isn't managed and also isn't pointed to your machine, the site itself won't point here even though it may create that domain as part of your setup process. It will exist on the server, but just not be used. After you create the domain you're welcome to remove any DNS records that you aren't using, such as the "cpanel" and "webmail" entries as that won't negatively impact the account at all. 0 -
I'm having an issue with Let's Encrypt not validating these domains: It's trying to perform DCV on the root domain which is not hosted on the server, only wildcard domains are. How do I fix this? Can I somehow instruct Let's Encrypt to perform DCV on a subdomain to verify the wildcard certificate? 0 -
While it may not be able to verify the root domain, it should then move on to any other domains that are set up on the account. Is that not happening? 0 -
I'm not sure I understand the question. There are other domains on the account that have the root domain hosted on the server and they're passing. The system isn't securing SSL certificates for the wildcard domains described in the original post. 0 -
Is the domain actually configured on the server as *.domain.com? 0 -
Yes, here you can see the line items: Also the root domains are listed since there's no way to exclude them: 0 -
The _cpanel-dcv-test-record and _acme-challenge DNS records are pointed to the server. That worked in the initial setup, I'm not sure why it's not working now. 0 -
If you'd like to submit a ticket we'd be happy to check the configuration of the machine and make sure everything is in place. 0 -
For the record, I opened a ticket for this, and it's not going well. I'm getting passed between so many different support people, and each one starts over without thoroughly reading the ticket and coming up with new explanations or bringing up issues that have already been addressed. My responses and questions go unanswered, there's no consistency whatsoever. The root domain DNS (i.e. REDACTED) has the DCV subdomain records (_cpanel-dcv-test-record and _acme-challenge) set to my server's nameservers (it was ns1.bid.glass and ns2.bid.glass but someone told me to switch it to server.bid.glass and then I got passed off to someone else). A dig of _cpanel-dcv-test-record.REDACTED.io has no answer. A dig trace of _cpanel-dcv-test-record.REDACTED shows that my cPanel server is the one responding. A DNS lookup for the TXT record for _cpanel-dcv-test-record.carsheet.io reports the TXT record set by my cPanel server. What's going wrong here? 0 -
Changing nameservers doesn't sound like something we'd normally recommend. Can you post the ticket number here so I can review the situation? 0 -
94323479 0 -
Thanks for that - I do see the ticket was escalated from Level 1 support and eventually making its way to Level 3, and was only passed to new technicians while shift changes were happening. If you don't believe the ticket was handled properly, you can request to work directly with a supervisor through that ticket and we'll be happy to do that. It still seems there are problems with the DNS configuration with those records that is keeping the workaround from working properly. It's also worth noting that the configuration you're trying to implement is not something that is officially supported. 0 -
I'm just trying to find a solution. 0 -
I honestly don't think there is a perfect solution here as the method you are trying to get AutoSSL working isn't something that is officially supported by either cPanel or Let'sEncrypt. 0 -
Well, it did work originally, that's why there are valid wildcard SSL certificates for those domains in the first place. According to the logs, Let's Encrypt is only attempting HTTP-based DCV, not DNS-based DCV. I wonder if it would pass if it attempted DNS-based DCV because the TXT records are getting updated correctly, but I don't know how the authentication process is managed by WHM/Let'sEncrypt. 0 -
I see you've replied with that into to the ticket as well, so the level 3 techs will be replying to that soon with more details. 0 -
Our team was able to recommend some possible DNS tweaks. Can you try those and report back to the ticket to see if that helps? 0 -
I've tried everything recommended so far. 0 -
Our Level 4 technician team was able to conclude that the custom workaround is a not a valid procedure, and it has since been removed from our support pages. I'm sorry if that document led you down the wrong path. They outlined another workaround that could potentially get things working, and also mentioned the certbot that Let's Encrypt has available. 0 -
[QUOTE]They outlined another workaround that could potentially get things working
This is your Level 4 tech's solution: [QUOTE]So the solution is to change the _name.com name servers from A to TXT. Then it should pass DCV (via DNS) and issue the SSL. Please try that and let me know if we can be of further assistance.
In other words, he's suggesting I set the TXT records at the remote root DNS (which, by the way, I've already stated multiple times that I don't have control over the remote root DNS except to ask clients to set NS records for the DCV subdomains to point to our DNS). The DCV subdomain TXT records are generated by cPanel and updated to the local DNS during the AutoSSL renewal process. How then would manually updating the TXT records at the remote root DNS before attempting AutoSSL renewal then solve this? New DCV values will be generated during the AutoSSL process and be assigned to the local DNS and not the remote DNS and the checks will fail. The whole point of delegating the NS for the DCV subdomains to the local DNS is to that they are considered the NS authority for those subdomains and therefore the local TXT records will be read and the checks will pass. Sure, remove the article because clearly your team doesn't know how to get it to work.0 -
We removed the article not because we aren't able to get it to work, but because the workaround didn't appear to be valid with our testing. We don't want to have bad information out there. The issue is that AutoSSL just isn't designed to do what you're trying. You'd have much better luck with the certbot tools handling this rather than trying to move AutoSSL certs to another location. 0 -
It still seems to me that the problem is that the system is attempting HTTP DCV on the wildcard subdomains rather than DNS DCV and/or the cPanel server is not giving answers for NS requests of the DCV subdomains, i.e. "dig _acme-challenge.onezo.org NS @ns1.bid.glass" even though a "dig +trace _acme-challenge.onezo.org NS" clearly shows the NS authority has been delegated to ns1.bid.glass (the same result when the NS is set to server.bid.glass we've tried both multiple times). 0 -
dig _acme-challenge.onezo.org TXT [QUOTE];; ANSWER SECTION: _acme-challenge.onezo.org. 14074 IN TXT "AAL1GMsqDB1EqN5yQqVCe9uxQw056tiX8xFlblcHCCw" 0 -
At this point we really need to continue to work through the ticket. 0 -
I suspect that the issue is that cPanel's AutoSSL process is adding an extraneous "local authority" check to wildcard subdomains instead of delegating that process to Let's Encrypt and allowing DNS-based DCV to proceed. If DNS-based DCV would occur, Let's Encrypt would check the TXT records and the tests would pass. 0 -
After 100 or so emails back and forth, cPanel has informed me that fully supporting Let's Encrypt is not within the scope of their implementation. I got this working on a Webmin server in less than an hour, if anyone is looking for how to do this: Let"s Encrypt wildcard certificates, acme.sh and automated DNS verification " The ongoing struggle 0 -
I did mention earlier on that this type of implementation isn't something that we support, as we require the DNS to be hosted locally on the cPanel server for wildcard certificates to work properly. While that isn't necessarily something that Let's Encrypt enforces, we added that to the cPanel implementation for additional security. Official details are here in the blue "Note" box: The Let's Encrypt Plugin | cPanel & WHM Documentation I can't speak for the Let's Encrypt tools outside of cPanel as that isn't something we test on our end, but everything does seem to be working as intended at this time. That was further confirmed by our Level 3 technicians, and the ticket was also escalated to management, so we did explore all the options of support for this particular issue. 0
Please sign in to leave a comment.
Comments
31 comments