SSL certificate application, deployment and expiration check
Prepare domain name and verify permissions, confirm specifications and deliverable content, complete HTTPS deployment and verify certificate coverage, validity period and business access.
Contents of this article
First confirm the domain name that needs to be protected
Before applying, list all domain names actually accessed by users, including main domain names, subdomain names, APIs, and old domain names that need to be redirected, and then confirm that the selected certificate can cover them. This site SSL product pageProvides instructions for single domain, multiple domain, and wildcard DV certificates, and outlines the process for submitting a domain through customer service, completing ownership verification, and receiving the certificate.
For common checking items for accounts, lines and orders, see Purchase requirements and billing。
Conditions you should meet before applying
- Have management rights for the applied domain name and be able to complete domain name ownership verification as required by the order.
- When using DNS verification, the corresponding resolution can be managed; when using file verification, the verification file can be deployed to the required address and make the verification request accessible.
- Ability to manage the actual server, proxy or SCDN website configuration that terminates HTTPS and arrange for installation and verification.
- Coverage, certificate types, validity periods, fees, delivery methods, renewal arrangements and cancellation rules for all domain names have been confirmed.
- Confirm the certificate brand, purchase service cycle and validity period of a single certificate respectively, as well as the responsibilities and fees for re-issuance, re-verification and deployment within the cycle.
According to the issuance requirements of this CA and order, select the allowed domain name verification method and prepare the corresponding records or verification documents. The verification method of wildcard certificates needs to be checked individually, and it cannot be assumed that the file verification used for ordinary domain names is also applicable.
What information needs to be provided
| Information | Fill in the content |
|---|---|
| Domain name list | Itemize the complete domain names that need to be protected; wildcard requirements also indicate whether the main domain name needs to be covered |
| Deployment location | Origin, load balancer, gateway or SCDN; software and version used |
| Verification conditions | Do you have DNS management rights and can you deploy publicly accessible verification files? |
| Current certificate | If it is a replacement or renewal, provide the current expiration time, covered domain name and deployment location. |
| Delivery requirements | The certificate format required by the server and who generates and keeps the private key |
| Online arrangement | Contact information, change window, clients that need to be compatible and the person in charge of acceptance |
The CSR, private key generation method, certificate chain file and installation format should be confirmed with the service team and the actual deployment environment. Private keys are processed through agreed controlled channels and are not included in public articles or screenshots of questions.
Application and deployment process
- Confirm specifications and order. Submit the complete domain name list to customer service and confirm the certificate coverage, validity period, fee, verification method and delivery scope before applying.
- Complete domain name verification. Use the records or files provided by this order; do not reuse verification values from old orders, and do not guess the record type or verification path.
- Check the certificate file. After receiving it, check the corresponding relationship between the domain name, validity period, certificate chain and private key, and confirm that they are consistent with the deployment environment requirements.
- Deploy to actual HTTPS portal. Configure the certificate according to the method currently supported by the server or console, and retain the original configuration. When the origin and edge use HTTPS at the same time, the two connections should be checked separately.
- Verify business access. First confirm that HTTPS is normal, and then adjust the forced redirect according to business needs; after completion, check all domain names and key processes.
When using certificates with SCDN, continue readingCDN website managementHTTPS setup instructions, and are subject to the current console.
How to verify successful deployment
| Check items | Suggested verification method |
|---|---|
| actual certificate | Check the certificate returned online through the browser to confirm that it has been switched to the target certificate. |
| Domain coverage | Visit the domain names in the list one by one to confirm that there are no domain name mismatch errors. |
| Validity period and chain of trust | Check validity period, certificate chain and browser trust status |
| Pages and Resources | Check images, scripts, styles and download addresses to avoid resources still using connection methods that do not meet business requirements |
| business process | Complete login, API, payment callback or other key operations to confirm client compatibility |
| Jump | Check the target, port and path from HTTP to HTTPS to confirm there are no loop jumps |
| Return to the source | When using HTTPS to return to the origin, check the origin certificate and the return-to-origin connection result at the same time. |
If the browser still displays the old certificate, you should check the actual domain name, entrance and deployment location, and then confirm whether the configuration has taken effect. If you encounter a trust chain error, domain name mismatch, or handshake failure, retain the error information and check the corresponding configuration.
Expiration, replacement and rollback
Record the expiration time, domain name, deployment location and responsible person for each online certificate, and arrange renewal or replacement in advance. Re-issuance does not mean that the online replacement has been completed. The certificate returned by the real access needs to be checked again after deployment.
Confirm the renewal reminder, automatic deployment and old certificate retention methods with the service team, and record the processing arrangements for this renewal.
If an exception occurs after installing the new certificate, you can restore the old certificate that is still valid and matches the domain name according to the previously saved configuration, and then retest. If the old certificate has expired or is not applicable, you should contact support for processing.
Contact technical support
PassOnline customer serviceExplain "SSL Certificate Application" or "Certificate Deployment Abnormality" and provide the order, domain name, deployment environment, time and error information. See other existing channelsContact us。