Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
There was a problem while issuing a new certificate for a customer in our portal, and I have a question about it.
The client's domain cannot be made public, so I made a similar situation with my personal domain.
When the private IP of the domain to issue the certificate is resolved,
In letsdebug.net, it is checked as follows.
In our existing process, domain validation information can be checked after Let's Encrypt is verified.
However, in this case, even the verification step of Let's encrypt did not pass by using a private IP.
Currently, public IP cannot be set, but DNS domain can be set.
To proceed with DNS validation like the debug result, how can I check the DNS validation token?
If you intend to use DNS validation, then the IP address in the A record doesn't matter.
If your ACME client supports DNS-01 challenges, you could request a certificate for any .dopark.xyz domain by fulfilling the challenge: setting up a TXT record with the correct key authorization value.
How exactly you do this, depends on how your ACME integration / ACME client works. We'd need more information about whether you use Certbot or something else to create these certificates.
Certificate generation is carried out in akamai's Certificate Provisioning System.
Requested to create a new certificate, and the pending status has been confirmed for a long time.
I didn't even get to the steps necessary for verification, such as http token or dns txt recode.
So I checked with the debug link.
I don't think you will get much help debugging DNS validations using Let's Debug.
You should try using the staging environment for actual testing and debugging (not production).
I assume that you'd have to get Akamai's system to do the DNS challenge. Best off asking Akamai about that.
Your nameserver setup seems a bit off:
$ dig +noall +answer dopark.xyz ns
dopark.xyz. 3538 IN NS ns52.domaincontrol.com.
dopark.xyz. 3538 IN NS ns51.domaincontrol.com.
dopark.xyz. 3538 IN NS a18-65.akam.net.
The Akamai nameserver answers with REFUSED for your zone, which suggests that your domain has not been setup on Akamai, or that you're using the wrong Akamai nameservers.
Mixing two GoDaddy nameservers with one Akamai nameserver is unusual as well. I'd guess it was a mistake, but perhaps you could elaborate on how your domain is setup?
Either of these problems could credibly be the reason you can't get a certificate.
The "forbidden by policy" error is due to Let's Encrypt blacklisting certain high-profile domains as a precaution. Have a read of this post for more information.
What changed is that you selected DNS as the challenge method in Let's Debug. In the test that failed, you selected HTTP. You can see this in the history here.
Well, Akamai won't be able to perform the DNS challenge unless you are using Akamai nameservers.
If you continue to use GoDaddy nameservers, then HTTP is the only choice you have for the challenge. That won't work because of the private IP address.
It would seem that if you want this to work, you need to use Akamai nameservers only for dopark.xyz.
That won't affect the "forbidden by policy" error, though—that's enforced based on the subject name in the certificate rather than anything related to the challenge methods.
