Troubleshoot domain ownership verification issues

You can use the Alibaba Cloud network diagnostic tool to check if your DNS record has taken effect. Follow these steps:

Common causes and solutions are as follows:

1. The DNS record has not been added.

   Refer to Domain ownership verification, go to your DNS provider, and manually add a CNAME or TXT record for domain ownership verification.

2. Console verification delay.

   If you have correctly added the DNS record but the console still displays "No DNS record found.", this may be due to a DNS resolution delay in the console. No action is required. Wait patiently and try again later.

3. The domain bound to the SSL certificate does not match the domain configured in DNS.

   Note

   If you are not using Alibaba Cloud DNS, go to your DNS provider to confirm the domain information.

   1. Confirm that the domain names match.

      Log on to the Alibaba Cloud console, find the target domain name (labeled cert) on the Alibaba Cloud DNS > Authoritative Domain Resolution page, then check the bound domain name of the corresponding certificate on the Certificate Management Service > SSL Certificate Management page, and compare whether the two are consistent.

   2. On the SSL certificate verification page, click Modify, re-enter the domain name bound to the certificate, and submit the application again.

      In the Verification Information step of the certificate application page, if DNS verification fails and the message No DNS record detected is displayed, you can click Modify to the right of the error message to reconfigure the DNS resolution record, or click View Record Value to verify that the host record and record value match those added in the domain management console.

Common causes and solutions are as follows:

1. The DNS record value is configured incorrectly.

   Re-copy the host record and record value from the certificate application page, and paste them into your DNS configuration.

   Make sure that the DNS resolution record is configured correctly: On the SSL certificate Verification Information page, select the TXT verification method, use the copy button to copy the Host Record and Record Value from the table, then in the Add Record form on the domain management console, set Record Type to TXT, paste the copied host record and record value into the corresponding Host Record and Record Value fields, set DNS Request Source to Default, set TTL to 10 Minutes (Recommended), and click Verify.

2. You are using DNSPod or another third-party DNS provider.

   You can ignore the error in the console. Configure the DNS record as required at DNSPod or your other DNS provider, and then wait for the CA to complete the verification.

3. The record value for a DigiCert DV certificate is more than 24 hours old.

   1. Delete the TXT record that is more than 24 hours old.

   2. Go to the Certificate Management Service console, reapply for the certificate, and obtain the latest TXT record value.

   3. Go to your DNS provider's platform and add the new TXT record.

   Note

   The timestamp for GeoTrust DV certificates is always valid and is not subject to this limitation.

4. The record value has not been synchronized to overseas DNS servers.

   The synchronization of dynamic DNS records may be delayed, causing overseas authoritative DNS servers to be unable to retrieve the latest TXT record value. Check whether the dynamic DNS service is running normally and wait patiently.

A network exception has occurred on the domain name server. Contact the corresponding domain name provider to check and fix the network issue.

Common causes and solutions are as follows:

1. The verification file has not been uploaded to the specified directory on the server.

   Refer to Domain ownership verification, and upload the verification file to the specified verification directory on your web server (.well-known/pki-validation/).

2. Console file verification delay.

   If you have uploaded the verification file to the specified directory on the server, and you can access the verification file content through both HTTPS Address and HTTP Address, but the console still displays "No file found.", this may be due to a file verification delay in the console. No action is required. Wait patiently and try again later.

Common causes and solutions are as follows:

1. Port 80 or 443 is not open on the server.

   The CA center can only verify the file content by accessing HTTPS Address and HTTP Address (port 443 and port 80, respectively).

   Solution 1: Open port 80 or 443.

   How do I open port 80 or 443?

   Linux

   1. Run the following command in the server terminal to check whether port 443 is open:

      RHEL/CentOS

      command -v nc > /dev/null 2>&1 || sudo yum install -y nc
      # Replace <your_server_public_ip_address> with the public IP address of your server.
      sudo ss -tlnp | grep -q ':443 ' || sudo nc -l 443 & sleep 1; nc -w 3 -vz <your_server_public_ip_address> 443

      If the output contains Ncat: Connected to <your_server_public_ip_address>:443, port 443 is open. Otherwise, you must open port 443 in the security group and firewall.

      Debian/Ubuntu

      command -v nc > /dev/null 2>&1 || sudo apt-get install -y netcat
      # Replace <your_server_public_ip_address> with the public IP address of your server.
      sudo ss -tlnp | grep -q ':443 ' || sudo nc -l -p 443 & sleep 1; nc -w 3 -vz <your_server_public_ip_address> 443

      If the output contains Connection to <your_server_public_ip_address> port [tcp/https] succeeded! or [<your_server_public_ip_address>] 443 (https) open, port 443 is open. Otherwise, you must open port 443 in the security group and firewall.

   2. Open port 443 in the security group.

      Important

      If your server is deployed on a cloud platform, make sure that its security group allows inbound traffic on TCP port 443. Otherwise, the service is not accessible from the internet. The following operations use an Alibaba Cloud ECS instance as an example. For other cloud platforms, see their official documentation.

      Go to the ECS Instances page and click the name of the target instance to go to its details page. For more information, see Add a security group rule. Add a rule to the security group with Action set to Allow, Protocol Type set to TCP, Port Range set to HTTPS(443), and Authorization Object set to Anywhere (0.0.0.0/0).

   3. Open port 443 in the firewall.

      Run the following command to identify the current firewall service on your system:

      if command -v systemctl >/dev/null 2>&1 && systemctl is-active --quiet firewalld; then
          echo "firewalld"
      elif command -v ufw >/dev/null 2>&1 && sudo ufw status | grep -qw active; then
          echo "ufw"
      elif command -v nft >/dev/null 2>&1 && sudo nft list ruleset 2>/dev/null | grep -q 'table'; then
          echo "nftables"
      elif command -v systemctl >/dev/null 2>&1 && systemctl is-active --quiet iptables; then
          echo "iptables"
      elif command -v iptables >/dev/null 2>&1 && sudo iptables -L 2>/dev/null | grep -qE 'REJECT|DROP|ACCEPT'; then
          echo "iptables"
      else
          echo "none"
      fi

      If the output is none, no further action is required. Otherwise, based on the firewall type (firewalld, ufw, nftables, or iptables), run the corresponding command to open port 443:

      firewalld

      sudo firewall-cmd --permanent --add-port=443/tcp && sudo firewall-cmd --reload

      ufw

      sudo ufw allow 443/tcp

      nftables

      sudo nft add table inet filter 2>/dev/null
      sudo nft add chain inet filter input '{ type filter hook input priority 0; }' 2>/dev/null
      sudo nft add rule inet filter input tcp dport 443 counter accept 2>/dev/null

      iptables

      sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

      To prevent iptables rules from being lost after a system reboot, run the following command to make the rules persistent:

      RHEL/CentOS

      sudo yum install -y iptables-services
      sudo service iptables save

      Debian/Ubuntu

      sudo apt-get install -y iptables-persistent
      sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null

   Windows

   1. Open port 443 in the security group

   Important

   If your server is deployed on a cloud platform, make sure that its security group allows inbound traffic on TCP port 443. Otherwise, the service is not accessible from the internet. The following operations use an Alibaba Cloud ECS instance as an example. For other cloud platforms, see their official documentation.

   1. Go to the ECS Instances page, select the region where your target ECS instance is located, and click the instance name to go to the details page.

   2. Click Security Groups > Inbound Rules and make sure a rule exists with Action set to Allow, Protocol Type set to TCP, Port Range set to HTTPS(443), and Authorization Object set to Anywhere (0.0.0.0/0).

   3. If such a rule does not exist, add one to the target security group. For more information, see Add a security group rule.

   2. Open port 443 in the server firewall

   1. Log on to your Windows server, click the Start menu, and then open Control Panel.

   2. Go to System and Security > Windows Defender Firewall > Check firewall status.

   3. If the firewall is turned off as shown in the following figure, no further action is required.

   4. If the firewall is turned on, follow these steps to allow HTTPS traffic.

      1. In the left-side navigation pane, click Advanced settings > Inbound Rules and check whether an inbound rule exists for which Protocol is TCP, Local Port is 443, and Action is Block.

      2. If such a rule exists, right-click the rule, select Properties, and on the General tab, change the action to Allow the connection. Then, click Apply.

   Solution 2: In the Apply for Certificate panel, click Cancel Application, and change the domain verification method to Manual DNS Verification.

2. A 301 or 302 redirect is configured.

   • Use the wget -S <URL> command to check whether the verification URL has a redirect. If the response is HTTP/1.1 301 Moved Permanently or HTTP/1.1 302 Found, a redirect exists.

     wget -S http://<your_domain>/.well-known/pki-validation/<verification_file_name>

   • Remove the redirect configuration. The following examples show 301 and 302 redirect configurations in the Nginx configuration file nginx.conf.

     301 redirect

     server {
         listen 80;
         server_name <your_root_domain> <your_www_subdomain>;
         return 301 <redirect_domain>$request_uri;
     }

     302 redirect

     location /.well-known/ {
         return 302 <redirect_address>
     }

• Overseas CA IP addresses are blocked by a firewall (the website does not support overseas access).

  If you apply for an international brand certificate (such as DigiCert or GlobalSign), but the website bound to the certificate domain restricts access from overseas IP addresses, you can temporarily add the CA center's IP addresses to the server whitelist.

  Note

  • For information about how to obtain the IP addresses of the CA center, see CA IP Addresses, or contact a technical expert. For more information, see one-on-one technical support.

  • After the certificate is issued, we recommend that you remove the configured IP whitelist to avoid issues when applying for certificates in the future.

• A network exception has occurred on the domain name server.

  Contact the corresponding domain name provider to check and fix the network issue.

• The domain name applied for a free test certificate contains sensitive words.

  Solution 1: Use a domain name that does not contain sensitive words (such as edu, gov, org, jp and other country abbreviations, as well as pay, bank, live, and nuclear), and submit the application again.

  Solution 2: If the domain name cannot be changed, purchase an OV or EV certificate, or a vTrus (a Chinese brand) certificate.

Common causes and solutions are as follows:

1. An old verification file exists on the server and has not been deleted.

   1. In the Apply for Certificate panel, click View Detected File, and in the dialog box, compare Files You Need to Add with Detected Files to confirm that old verification files exist on the server.

   2. Go to your web server and delete the detected old file.

      Note

      Old files are typically located in the site root directory/.well-known/pki-validation directory.

   3. Refer to Domain ownership verification to download the latest verification file and upload it to your web server.

2. The verification file is deployed only to the HTTP path, not to the HTTPS path.

   Some site pages have enabled HTTPS access, but the verification file is deployed only to the HTTP service path and has not been deployed to the HTTPS service path, which causes the verification to fail.

   Solution 1: Deploy the verification file to both the HTTP and HTTPS service paths, and ensure that it can be accessed over HTTPS.

   Solution 2: Temporarily disable the HTTPS service for the relevant site pages.

3. CDN is enabled, but the verification file has not been synchronized to overseas CDN nodes.

   Solution 1: Synchronize the verification file to overseas CDN nodes, or temporarily disable the CDN overseas acceleration service.

   Solution 2: If you cannot modify the CDN node server configuration, go to the Apply for Certificate panel, click Cancel Application, and change the domain verification method to Manual DNS Verification.

4. The verification file timestamp has expired.

   Go to the Certificate Management Service console, download the latest verification file, and upload it to the specified directory on your website.

• The www subdomain and the root domain are not both covered by the verification.

  According to CA verification requirements, regardless of whether you apply for the root domain or its www subdomain, the CA checks both addresses simultaneously. Make sure that the verification file is publicly accessible on both domains. Otherwise, the verification will fail.

  Note

  For example, for www.example.com and aliyundoc.com, you must ensure that both http://www.example.com/.well-known/pki-validation/fileauth.txt and http://example.com/.well-known/pki-validation/fileauth.txt are accessible. Otherwise, the verification will fail.

• The HTTPS service is not ensured to be accessible for the verification file.

  If the server has enabled the HTTPS service, you must ensure that the verification file content can be accessed through HTTPS Address. Otherwise, the verification will fail. We recommend that you temporarily disable the HTTPS service for the domain.

  Note

  If the server has never been configured with an HTTPS service, you only need to ensure that the verification file content can be accessed through HTTP Address.

No. For more information, see [Notice] File verification is no longer supported for wildcard certificate applications.