Guide to domain validation
This page only applies to SSL Server certificates.
As part of the SSL Server certificates' issuance procedure, it is mandatory that the Applicant proves to the CA to have full control of all the domains
(FDQN) to be included in the requested certificate. This verification (Domain Control Validation
) may only be done with methods approved by the CAB Forum
. Except for special cases, the DCV process also requires actions by the Applicant.
Actalis currently supports the DCV methods described in the following table:
||The CA sends an email to the administrator of the domain to be validated (or of a higher level domain), to one of the standard privileged mailboxes, namely: postmaster, webmaster, hostmaster, administrator, admin@domain. The email contains a unique link that the recipient is required to click, then following the instructions shown by the browser. The CA waits for the recipient to read the email and proceed in the expected manner, to prove that the Applicant has control of the domain.
||Similar to the previous method, but the email is sent to a mailbox found in the domain's WHOIS record. Also in this case, the CA waits for the recipient to read the email, click on the link therein, and follow the instructions shown by the browser. This method assumes that at least one email address is found in the output of the whois <domain> command. If the email address can only be seen via different query modes (e.g. via the domain registrar's web site), then this method requires the manual intervention of a CA operator, delaying the validation process. This method is supported, but not recommended.
||To prove its control of the domain, the Applicant must publish a plain text (.txt) file on the domain's (or a higher level domain's) HTTP server. The file must contain a unique confirmation value generated by the CA (*), without spaces or newlines, and must be published at the following URL:
The CA will automatically check that the said file is found on the server, in the expected path and with the expected contents. To create the text file actalis.txt we recommend to use a plain text editor (e.g. Notepad under Windows).
Please take note that:
- no other path may be used (it is a standard)
- the period "." before "well" is not a typo: it is required
- HTTP redirects are not followed by the CA
||To prove its control of the domain, the Applicant must publish a suitable TXT record on the domain's (or a higher level domain's) DNS server. The TXT record must have the following value:
…where confirmationValue is a unique confirmation value generated by the CA (*). The CA will automatically check that the expected TXT record is present on the domain, with the expected value. To verify the proper publication of the TXT record, you can use the nslookup command (under Windows) or the dig command (under Linux).
||This method may only be used for domains registered and managed by Aruba. In such a case, no actions are required of the Applicant to prove control of the domain.
The CA itself will verify the database of domains managed by Aruba S.p.A. In this case, validation may take several hours, depending on the availability of operators.
(*) This value is communicated to the Technical Contact by the Actalis customer care team (in case of certificate requests via email) or it is displayed to the Applicant (in case of web-based certificate requests).
- Domain validations must complete within 30 days, after which they are regarded as failed.
- After successful domain validation, the domain remains valid for 12 months; during this period the Applicant can obtain one or more certificates containing that domain without the need for further validations; at the end of the 12 months from the last validation, to obtain further certificates containing that domain it is necessary to pass a new validation.
Warning: the range of supported methods for domain validation may change as a consequence of regulatory changes (e.g. updates to CAB Forum's Baseline Requirements) and/or in the event that some methods are proven to be vulnerable to security attacks.