Say youtube.com wants to generate their new certificate. How certification authority verify that the request came from youtube.com, not from a party pretending to be youtube.com?
-
3Does this answer your question? [Please help verify my understanding of Domain Validation (DV) SSL Certificate](https://security.stackexchange.com/questions/41289/please-help-verify-my-understanding-of-domain-validation-dv-ssl-certificate) – Marc Sep 18 '20 at 05:26
-
@Marc: I think the question/answer you link to is similar but outdated and is thus not really suitable as a duplicate. This was written before Let's Encrypt, the ACME protocol etc. – Steffen Ullrich Sep 18 '20 at 05:59
-
True, [How does LetsEncrypt.org's ACME work?](https://security.stackexchange.com/questions/107640/how-does-letsencrypt-orgs-acme-work) is more appropriate for newer protocols. – Marc Sep 18 '20 at 06:01
-
Does this answer your question? [How does LetsEncrypt.org's ACME work?](https://security.stackexchange.com/questions/107640/how-does-letsencrypt-orgs-acme-work) – multithr3at3d Sep 20 '20 at 21:47
2 Answers
There are a variety of methods to prove that the requester of a certificate owns a specific domain.
Usually these are based on some kind of challenge given by the CA which the requester must somehow associate with the domain in a way that the CA is able to check this association. This might be an entry on a special place on the domains web site, it might be some DNS record for the domain, it might be that the requester is able to receive a mail with the challenge to a specific account on this domain etc.
While these kind of domain validation (for DV certificates) can be automated there are additional manual checks by the CA for EV (extended validation) certificates.
And with your specific example of youtube.com the situation is different: certificate for this domain are not issued by a public CA but by Google itself. Google has a sub-CA issued by a public CA and can use it to issue their own certificates. How exactly this is done is not known to me, but I expect them to use a very different process described than described so far because there is no need for them to actually prove the ownership of a domain which they own themselves.
Note that the process of domain verification is not fully reliable. If attackers can get control over the domain or parts of it even for a short time they might be able to create valid certificates for the domain which then later can be used in MITM attacks. This actually happened in the past.
For more information including the more technical details see Let's Encrypt Challenge Types, How does LetsEncrypt.org's ACME work?, Please help verify my understanding of Domain Validation (DV) SSL Certificate.
Please also note the role of the (optional) CAA DNS records to restrict, which CA is even allowed to issue certificates for a specific domain. This somewhat addresses the risk that any CA can issue certificates for any domain.
![](../../users/profiles/37315.webp)
- 184,332
- 29
- 363
- 424
My answer will disregard the following:
Disregarding the payment part, which most CA's require for one to get the certificate. Also disregarding any automated (re)certification system, which is how large companies usually get (re)certification.
The following answer is for a simple answer for non-large organizations.
CA's will always ask for the website that you want to have the certificate for. Then they check to see if that website does indeed exist. Then they ask for an e-mail address that is associated with the domain that you are asking the certificate for. They will send the certificate and other info to that e-mail address, after they receive the payment.
![](../../users/profiles/235071.webp)
- 346
- 1
- 5
-
2This is one way to do it but not the only way. For example with Let's Encrypt the verification is not done by email but by putting some special file with special content on the web server or by putting some special data into DNS to prove ownership of domain. And with EV certificates even more checks are involved. – Steffen Ullrich Sep 18 '20 at 05:24
-
I know about lets encrypt, the certificate and the key usually have to be copied from the final success page to different files. I was only trying to give a general overview answer so I left it out. – Amol Soneji Sep 18 '20 at 05:26
-
2And with the specific example youtube.com it gets even more tricky. The issuing (sub-)CA in question is Google itself (`C = US, O = Google Trust Services, CN = GTS CA 1O`) and who knows what processes they have internally. – Steffen Ullrich Sep 18 '20 at 05:28
-
1*"I was only trying to give a general overview answer"* - you specifically point out email as the way for verification and don't even mention that others exist. This can not be considered a "general overview". – Steffen Ullrich Sep 18 '20 at 05:30
-
For a big company like Google, usually they will use a certification management software. When it comes to managing multiple domains for an organization, doing a (re)certification process manually is inefficient, usually you would want some automation involved. The process here is usually different than the e-mail or Let's Encrypt verification process. – Amol Soneji Sep 18 '20 at 05:31
-
I did state in the beginning part of my answer that I am disregarding some stuff. If you put those things in consideration, you get a much larger answer. However I did make the answer a bit better now. – Amol Soneji Sep 18 '20 at 05:32
-
1Actually you are disregarding this way how the majority of certificates gets issued today, which makes the answer not very useful. And yes, the answer gets large if one actually want to fully answer the question. But I think it is better to have a large answer (which are pretty common on this site) than to leave out the relevant parts. – Steffen Ullrich Sep 18 '20 at 05:33