If you've read the previous chapter, you'll have noticed a mention of certificates.

We explained how, once SSL is applied, the server and client communicate and handle data through encryption/decryption, but that's just the underlying principle of SSL.

So then, why exactly is a domain able to use https once SSL has been applied to it?

This is thanks to the existence of certificates. Whether SSL has been applied to a given site can be verified through the certificate information received during ServerHello, part of the HandShake process.

An SSL certificate includes the domain name, company information, and the server's public key, and this information enables verification of the domain's site validity as well as encrypted communication.

SSL certificates can be classified into three types — DV, OV, and EV — depending on the level of scrutiny applied during certificate review.

DV is a certificate issued based solely on verification of domain ownership.

• CN (Common Name): the domain name (a wildcard if it contains *)

Looking at the subject of the certificate information, you'll find no other information besides the domain data in CN.

The certificate policy for DV is 2.23.140.1.2.1. This can also be used to infer that a certificate is a DV certificate.

Since no factors other than the domain — such as ownership — are taken into account during review, the issuance process is simple and quick. It also tends to be relatively inexpensive. However, its trustworthiness is lower compared to other certificate types.

That's because it only guarantees that the domain actually exists, and guarantees nothing beyond that. Even if someone sets up a shell company for illegal purposes and dresses up a site to look legitimate, a DV certificate will still be issued for SSL. This issue arises precisely because the review criteria is domain ownership alone.

Of course, this is ultimately just a matter of simple "trust" — the encryption algorithm used by a DV certificate is no weaker than that of any other certificate type, so there's no issue with security itself.

It's a certificate type best avoided for trust-dependent services such as shopping malls or financial services.

Conversely, DV is well suited — both in terms of time and cost — for personal projects, small-scale sites, and similar cases that don't demand as much trust. If you want to see a DV certificate for yourself, visit a small personal site or blog. In the case of blogs, make sure to visit one that isn't tied to a platform like GitHub or NAVER, but is instead one where the person actually rents their own server and deploys directly, without relying on a platform.

This is a method of verifying that you are the owner of a domain by sending a verification email to the domain owner's email address.

This email can't just be anything — it must be an email registered with the DNS provider through which the domain was issued.

Unlike other verification methods, this is a method that allows verification even without access to port 80 over HTTP. If, for whatever reason, your site can't be accessed externally over port 80, this is the only verification method available.

This is a method of verifying that you are the owner of a domain by adding a DNS configuration.

A URL randomly generated by the CA is added to the A record in the DNS settings. Verification succeeds if accessing that URL returns an HTTP response code of 200.

Since only the domain owner can manage the DNS settings, adding the CNAME can be taken as proof of domain ownership.

You must be able to access the web page over port 80. Due to the particulars of your network environment, port 80 might not be open externally. In that case, you can use port forwarding to route an external port 80 to a different internal port. In the worst case, if port 80 itself is entirely blocked, or if you don't have the ability to configure port forwarding yourself, this method cannot be used for verification.

A .well-known folder is created at the web ROOT path, and a temporary file is placed inside it. The temporary file is a randomly generated hash value. Once this is deployed to the web server, the file can be accessed via that path in a browser.

An HTTP request verifies ownership in this manner, by requiring the owner to upload a specific file to the server and checking whether that file is accessible.

Likewise, this is a verification method that requires access to port 80.

OV is a certificate issued based on verification not only of the domain, but also of the company or organization that owns that domain.

Separately from verifying whether the submitted domain is valid, it also carries out verification of the organization or company that owns the domain.

• CN (Common Name): the domain name
• O (Organization): organization name
• L (Locality): locality (city/county/district)
• S (StateOrProvinceName): state/province
• C (CountryName): country

Looking at the subject of the certificate, you can see information such as the name, region, and country of the owning company/organization, in addition to the domain information.

The certificate policy for OV is 2.23.140.1.2.2. This can also be used to infer that a certificate is an OV certificate.

To prove that your organization/company genuinely exists, you must additionally submit documentation such as a business registration certificate.

Since verification of the owner and the exchange of documentation are involved, issuance doesn't happen instantly. The cost is also higher, and it typically takes a good 1 to 3 days. However, thanks to owner verification, it provides a broadly recognized level of trustworthiness.

This is the certificate type suited for most private companies' pages. Since OV certificates are applied on most sites, you can check for one just by visiting any reasonably well-established site. This very blog is also owned by GitHub as the subject, so you can check its OV certificate for reference.

This is a certificate issued after verifying detailed factors on top of DV and OV verification — such as proof of employment for the corporate operations manager, and the duration of corporate operation.

While OV verifies whether a company actually exists, EV verifies whether the company is being operated normally.

Looking at the subject of the certificate, you can see that a variety of information has been added beyond just the domain and company information.

The certificate policy for EV is 2.23.140.1.1. This can also be used to infer that a certificate is an EV certificate.

Also, unlike other certificate types, an EV certificate displays the company's signature right on the certificate itself. Referring to the photo above, the left side is EV, and the right side is OV or DV. This is how Microsoft Chromium Edge displays it.

Additionally, when accessed via IE, a Green Bar is applied to the address bar, visually indicating that EV has been applied to that domain. Note that Chromium-based browsers don't display this visually.

Due to the rigorous review process for the certificate, issuance can take more than two weeks, and the cost is also very high. In return, it provides an extremely high level of trustworthiness.

Because of this level of trustworthiness, it's used on pages such as public institutions, financial services, and shopping malls, where this kind of trust guarantee is needed. If you want to see an EV certificate for yourself, visit any bank's homepage.

Whether SSL has been applied can be verified by checking whether the site has an SSL certificate. At a glance, SSL certificates might all seem alike, but in fact there are several different types, and by checking the subject and policy of a certificate, you can determine what type of SSL certificate the site you're currently visiting is using.

Be sure to obtain the SSL certificate type that best matches the nature of the site to which SSL is being applied.

In the next chapter, we'll obtain a domain — a prerequisite step needed to get an SSL certificate.