Certificate Management Service:Domain ownership validation FAQ

Alibaba Cloud provides the Network Detect Tool to help you check whether a DNS record is in effect. To use the tool:

The following list describes common causes and solutions:

1. The DNS record is not added.

   For more information, see Manual DNS authentication. You can manually add a TXT record with your DNS provider to verify domain ownership.

2. There is a delay in console validation.

   If you have correctly added a DNS record but still see the message "No DNS record found.", this may be due to a delay in console verification. You can wait for a short period and then retry.

3. The domain name bound to the SSL Certificate does not match the domain name in the DNS record.

   Note

   If you do not use Alibaba Cloud DNS, you can go to your DNS provider's console to confirm the domain name.

   1. Confirm that the domain names match.

   2. On the SSL certificate validation page, you can click Modify, re-enter the domain name to bind to the certificate, and then submit it for review again.

The following list describes common causes and solutions:

1. The DNS record value is configured incorrectly.

   Copy the host record and record value from the certificate request and paste them into your DNS record configuration again.

   

2. You use DNSPod or another DNS provider for domain name resolution.

   You can ignore the error message in the console for now. After you configure the DNS record with DNSPod or your provider as required, wait for the CA to complete the validation.

3. For a DigiCert DV certificate, the DNS record value is more than 24 hours old.

   1. You can delete the TXT record value that is more than 24 hours old.

   2. You can log on to the Certificate Management Service console, reapply for the target certificate, and obtain the latest TXT DNS record value.

   3. You can go to your DNS provider's platform and add the new TXT record value.

   Note

   The timestamp for a GeoTrust DV certificate is always valid.

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

   Synchronization latency for dynamic DNS records can prevent authoritative DNS servers outside China from obtaining the latest TXT record value. You can check whether your dynamic resolution service is running correctly and wait for the synchronization to complete.

The DNS server has a network issue. You can contact your domain name provider to check and fix the network connection.

The following list describes common causes and solutions:

1. The validation file is not uploaded to the specified server directory.

   For more information, see File Verification. You can upload the validation file to the specified validation directory (.well-known/pki-validation/) on the site server.

2. There is a delay in console file validation.

   If you have uploaded the verification file to the specified server directory and can access the file content using the HTTPS Address and HTTP Address, but the console still displays the "File Not Detected" message, this may be due to a delay in the console's file verification. No action is required. You can wait for the system to retry automatically.

The following list describes common causes and solutions:

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

   Currently, the CA only supports accessing HTTPS Address and HTTP Address (port 443 and port 80) to verify that the content of the validation file is accessible.

   Solution 1: You can open port 80 or 443.

   How to 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> 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> 443

      If the output is Ncat: Connected to <your_server_public_ip>:443, port 443 is open. Otherwise, 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> 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> 443

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

   2. Open port 443 in your security group configuration.

      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 will be inaccessible. The following steps use Alibaba Cloud ECS as an example. For other cloud platforms, refer to their official documentation.

      Go to the Elastic Compute Service (ECS) instances page and click the target instance name to go to the instance details page. For more information, see Add a security group rule to add a rule in the Security Group Details section with Action set to Allow, Protocol to Custom TCP, Destination (Current Instance) to HTTPS (443), and Source to 0.0.0.0/0 (anywhere).

   3. Open port 443 in your firewall.

      Run the following command to identify the active 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, run the corresponding command below based on the output (firewalld, ufw, nftables, or iptables) 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 make sure that the iptables rules persist after a system reboot, run the following commands:

      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 access on TCP port 443. Otherwise, the service cannot be accessed from the Internet. The following steps use Alibaba Cloud ECS as an example. For other cloud platforms, see their official documentation.

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

   2. Click Security Group > All Intranet Inbound Rules, and make sure that a rule exists with the following settings: Authorization Policy is set to Allow, Protocol Type is TCP, Destination Port Range is HTTPS (443), and Authorization Object is set to Anywhere (0.0.0.0/0).

   3. If the preceding rule does not exist, see Add a security group rule to add the corresponding rule to the target security group.

   2. Open port 443 in the server's local firewall

   1. Log on to the Windows server, click the Start menu in the lower-left corner, and open Control Panel.

   2. Click System And Security > Windows Firewall > Check Firewall Status.

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

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

      1. In the left navigation pane, click Advanced Settings > Inbound Rules, and check for an inbound rule where the Protocol is TCP, the Local Port is 443, and the Action is Block.

      2. If such a rule exists, right-click it and select Properties. On the General tab, change the setting to Allow The Connection and click Apply.

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

2. A 301 or 302 redirection is configured.

   • You can use the wget -S <URL address> command to check whether the validation URL is redirected. If the response is HTTP/1.1 301 Moved Permanently or HTTP/1.1 302 Found, a redirection exists.

     wget -S http://<your_domain_name>/.well-known/pki-validation/<validation_file_name>

   • You can delete the redirection configuration. The following code provides examples of 301 and 302 configurations in the Nginx configuration file `nginx.conf`.

     301 configuration

     server {
         listen 80;
         server_name <your_primary_domain_name> <your_www_subdomain>;
         return 301 redirection_domain$request_uri;
     }

     302 configuration

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

• The DNS server has a network issue.

  You can contact your domain name provider to check and fix the network connection.

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

  Solution 1: You can replace special words (such as edu, gov, org, jp (country code), pay, bank, live, or nuclear) and submit the request again.

  Solution 2: If you cannot change the domain name, you can purchase OV, EV, certificates.

The following list describes common causes and solutions:

1. An old file on the DNS server is not deleted.

   1. In the Apply for Certificate panel, you can click View Detected File, and record information about the detected files.

   2. You can go to your DNS server and delete the detected file.

      Note

      Typically, the old file is in the site's root directory/.well-known/pki-validation directory.

   3. For more information, see File Verification. You can re-download the latest validation file and upload it to the DNS server.

2. The HTTPS service path is not deployed.

   Some site pages have HTTPS access enabled, but the validation file is deployed only in the HTTP service path, not the HTTPS service path. This causes an error.

   Solution 1: You can deploy the validation file in both the HTTP and HTTPS service paths, and confirm that the HTTPS protocol can be accessed normally.

   Solution 2: You can temporarily disable the HTTPS service for the relevant pages on the site.

3. CDN is enabled, but data synchronization to CDN points of presence (POPs) outside China is not complete.

   Solution 1: You can synchronize the validation file to the CDN POPs outside China, or temporarily disable the CDN acceleration service outside China.

   Solution 2: If you cannot make changes to the CDN point of presence servers, on the Apply for Certificate panel, you can click Cancel Application and change the domain validation method to Manual DNS Verification.

4. The validation file timestamp has expired.

   You can access the Certificate Management Service console, re-download the latest validation file, and upload it to the specified folder on your website.

• Incomplete validation for the www subdomain and primary domain name

  According to the validation specifications of the certification authority (CA), the CA checks both the primary domain name and its www subdomain, regardless of which one you are applying for. You must make sure that the validation file can be publicly accessed for both domain names. Otherwise, the validation will fail.

  Note

  For example, for the domains 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 validation will fail.

• The HTTPS service is not disabled

  If your server has an HTTPS service, you must ensure that the validation file content is accessible at the HTTPS Address. Otherwise, we recommend that you temporarily shut down the HTTPS service for the domain name to prevent validation failure.

  Note

  If an HTTPS service is not configured on the server, you only need to ensure that the validation file content is accessible at the HTTP Address.

No, it does not. For more information, see [Notification] File validation is no longer supported for wildcard certificate requests.