Certificate Management Service:Domain ownership verification

Automatic DNS verification

If your domain meets the conditions for automatic verification, the system selects Automatic DNS Verification by default and this selection cannot be changed.

After you submit the application, Alibaba Cloud automatically adds a DNS TXT record in the Alibaba Cloud DNS console to verify domain ownership. Verification is complete when the message Domain name verification succeeded appears below the Verify button.

If the message has not appeared, follow the instructions in the prompt, check the FAQ for help, and click Verify again.

The console may lag behind actual DNS propagation. If your DNS record has taken effect but the console still shows No DNS record found. after clicking Verify, wait a few minutes and try again.

Manual DNS verification

Manually add a TXT record at your DNS provider to verify domain ownership.

File verification

Phone

CA staff will call the contact phone number in your certificate application to verify the application information. Make sure the contact person's phone is available to receive the call.

Email

The CA sends a domain verification email to the contact email address in your application. Check your email promptly and follow the instructions in the message.

The email content varies by certificate brand. The following example is for reference only — the actual email you receive is the one that is valid.

GlobalSign example:

DNS verification

Can I switch from Automatic DNS Verification to a different method?

No. If the system defaulted to Automatic DNS Verification for your domain, you cannot switch to Manual DNS Verification or File Verification. To use a different method, use a separate Alibaba Cloud account to either purchase the certificate or manage the domain's DNS.

How do I check if a DNS record has taken effect?

Use Alibaba Cloud's Network Detect Tool:

1. In the Apply for Certificate panel, click View Record Value.

   

2. On the DNS tab, click OK.

   

3. If the resolution result in the Probe Check Result list matches your configured DNS record value, the record is in effect.

Why do I get a `No DNS record found.` error?

The most common cause is that the required TXT record has not been added at your DNS provider. Go to your DNS provider's console and add the record. For instructions, see the Manual DNS verification section above.

Other causes:

• DNS propagation delay. DNS changes can take up to 1 hour to propagate — especially to the CA's servers. If the record is correct, wait and click Verify again.

• Domain name mismatch. The domain in your certificate application must exactly match the domain where you created the DNS record. If they differ, click Modify on the validation page, correct the domain, and resubmit the application.

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

  

  

Why do I get a `Mismatch found in the DNS record.` error?

This error means the CA found a TXT record for your domain, but its value is incorrect. Start by re-copying the Host Record and Record Value from the certificate application panel — a copy-paste error is the most common cause.

Common mistakes to check:

Other causes:

• Third-party DNS provider (such as DNSPod). The Alibaba Cloud console may report an error even if the record is set up correctly at your provider. Ignore the console error and wait for the CA to complete its own verification.

• Expired TXT record for a DigiCert DV certificate. DigiCert DV certificate TXT records are valid for only 24 hours. If the record has expired:

  1. Delete the old TXT record from your DNS provider.

  2. In the Certificate Management Service console, reapply for the certificate to get a new TXT record value.

  3. Add the new TXT record to your DNS configuration.

  This 24-hour limit does not apply to GeoTrust DV certificates — their timestamps remain valid.

• DNS propagation delay. DNS changes may not have reached the CA's servers yet. Allow up to 1 hour and verify that your DNS service is working correctly.

Why do I get a `Verification timed out. Try again.` error during DNS validation?

This error indicates a network problem that is preventing the verification system from querying your domain's nameservers. Contact your DNS provider to investigate potential network connectivity issues on their end.

My DNS record has propagated correctly, but console verification keeps failing.

The console's check can lag behind actual DNS propagation. Even if dig shows the record is correct, the verification service may be reading from a cached or delayed state. Wait one minute and click Verify again.

How do I resolve an SSL verification failure caused by a CAA DNS record?

A Certification Authority Authorization (CAA) record restricts which CAs can issue certificates for your domain. If your chosen CA is not listed, verification fails. Fix it using one of the following options:

• Option 1: Delete the CAA record in your DNS provider's console (such as the Alibaba Cloud DNS console), then reapply for the certificate.

• Option 2: Add the certificate's CA to the CAA record, wait for the record to propagate, then reapply.

If your domain uses a CNAME record pointing to github.io, it inherits GitHub's CAA policy. Either temporarily pause the CNAME record, or add trust-provider.com, globalsign.com, and sectigo.com to your domain's CAA record.

How do I set up DNS verification if my domain isn't managed by Alibaba Cloud DNS?

File verification

Why do I get a `No file found.` error?

The CA's server could not find the verification file at the expected URL. Check the following:

• Wrong directory. The file must be in the /.well-known/pki-validation/ directory within your website's root folder.

• Console delay. If the file is in the correct location and accessible over both HTTP and HTTPS, the console check may simply be delayed. Wait a few minutes and click Verify again.

Why do I get a `Verification timed out. Try again.` error during file verification?

This error means the CA's servers could not connect to your web server — typically a network or server configuration issue.

Ports 80 or 443 are blocked. The CA connects over HTTP (port 80) or HTTPS (port 443). Make sure your server's firewall and any cloud security groups allow inbound traffic on TCP ports 80 and 443.

To check whether port 443 is open, run the appropriate command for your OS:

Linux (RHEL/CentOS)

command -v nc > /dev/null 2>&1 || sudo yum install -y nc
# Replace <your_server_public_ip> with your server's public IP address.
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.

Linux (Debian/Ubuntu)

command -v nc > /dev/null 2>&1 || sudo apt-get install -y netcat
# Replace <your_server_public_ip> with your server's public IP address.
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.

If port 443 is closed, open it in your security group and firewall.

Open port 443 in the security group (Alibaba Cloud ECS)

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

Open port 443 in the firewall (Linux)

Run the following command to identify the active firewall 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 needed. Otherwise, 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 persist iptables rules after a reboot:

• 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

Open port 443 in the security group and firewall (Windows)

1. Open port 443 in the security group.

   1. Go to the ECS instance page, select the region of the target instance, and click the instance name.

   2. Click Security Group > All Intranet Inbound Rules and check for a rule with Authorization Policy set to Allow, Protocol Type set to TCP, Destination Port Range set to HTTPS (443), and Authorization Object set to Anywhere (0.0.0.0/0).

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

   Important

   The following steps use Alibaba Cloud ECS as an example. For other cloud platforms, refer to their official documentation.

2. Open port 443 in the Windows Firewall.

   1. Click Start > Control Panel > System and Security > Windows Firewall > Check firewall status.

   2. If the firewall is off, no further action is needed.

   3. If the firewall is on, click Advanced settings > Inbound Rules and look for a rule where Protocol is TCP, Local Port is 443, and Action is Block. If such a rule exists, right-click it, select Properties, and on the General tab, change the setting to Allow the connection, then click Apply.

Alternative: If you cannot open the required ports, cancel the application and reapply using Manual DNS Verification.

A URL redirect is configured on my server.

The CA's verifier does not follow 301 or 302 redirects. To check for redirects, run:

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

If the output includes 301 Moved Permanently or 302 Found, temporarily disable the redirect rules in your web server configuration that affect the /.well-known/pki-validation/ path. The following examples show how to identify and disable 301 and 302 redirects in an nginx.conf file.

301 redirect configuration example:

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

302 redirect configuration example:

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

An IP allowlist is blocking the CA.

If your server or network firewall restricts access to specific IP addresses, it may block the CA's verification servers. Temporarily add the following IP address ranges to your firewall's allowlist:

Why do I get a `File content is invalid.` error?

This error means the CA found a file at the verification URL, but its content is incorrect. Common causes:

• The root domain and www subdomain cannot both access the verification file. The CA checks for the file on both your-domain.com and www.your-domain.com. Make sure your server serves the file for both hostnames. For example, both of these URLs must be accessible:

  • http://aliyundoc.com/.well-known/pki-validation/fileauth.txt

  • http://www.aliyundoc.com/.well-known/pki-validation/fileauth.txt

• The verification file was opened, edited, or renamed. In the Verify Information panel, click View Detected File and compare its content with the latest verification file. If they differ, download and upload the verification file again, then retry verification.

  

• The file is inaccessible over HTTPS. If your site uses HTTPS, the CA will attempt to access the file over a secure connection. Either ensure your HTTPS configuration serves the file correctly, or temporarily disable the HTTP-to-HTTPS redirect for the verification path.

• A CDN is serving a stale or incorrect file. If you use a CDN, an edge node may be caching an old version of the file. Sync the verification file to CDN nodes outside China, or temporarily disable CDN acceleration for regions outside China. If you cannot update the CDN, click Cancel Application and switch to Manual DNS Verification.

• The verification file has expired. The downloaded file is valid for only 3 days. Download a new verification file from the console and upload it to your server.