イマドキの証明書は全部マルチドメイン証明書

# はじめに
マルチドメイン証明書とワイルドカード証明書も、複数のドメインを1枚の証明書でSSL/TLS化できるということは同じ。ここのまとめはよくまとまっている。
https://www.bestssl.net/faq/hikaku-wild-sans/

このまとめに加えて、いくつか最近の事情について補足をした方がよさそうなので、以下に記載。

# マルチドメイン証明書とは？

証明書には、CN(Common Name)という必須項目がある。例えば、ブラウザでのURL入力時に`https://www.example.org/index.html` にアクセスする際には、FQDN(`www.example.org`)がCNフィールドに設定されているFQDNと一致している証明書が使われていた（過去形にした理由は、後述を参照）。

<img width="618" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8a71c097-05ca-471a-6dd0-f2fa4bde2359.png">

しかし、CNというフィールドは１つのFQDNしか登録できない。

- `www.example.org`だけでなく、`www.example.com`や`www.example.net`など複数のドメインも１つの証明書で管理したい。
- `www.example.org`と`www.dev.example.org`のように階層が異なるドメインも１つの証明書で管理したい。


という要件を満たすために、「従来のSSL/TLS証明書の拡張領域を使い、そこで異なるドメインまで一緒に管理しよう」というのがマルチドメイン証明書の考えである。この拡張領域のことをSAN（Subject Alternative Name／サブジェクトの別名）と呼ぶ。以下の例では、計8つのドメインが１つの証明書で利用可能になっていることがわかる。

<img width="619" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/9b3e3785-6e85-33d3-ee69-122bc99dee27.png">

# マルチドメイン証明書は今では必須。

もともとはこのSANは拡張機能であり、複数のドメインを１つの証明書に集約するためのオプションであった（別に必須オプションではなかった）。**しかし、今では事情が異なっており、CNではなくSANを使うことが推奨されている**。これは2000年に発行された[RFC 2818](https://tools.ietf.org/html/rfc2818)に準拠するためである。これによると、サーバーの身元証明の方法として、SANの利用を推奨し、CNの利用は非推奨としている。

>If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

これを受けて、いろいろなブラウザやシステムでも、既にCNの代わりにSANを使うように変わってきている。つまり、現在のほとんどのサイトでは「SSL/TLS証明書=マルチドメイン証明書」となっている。

- Chrome: 
    - Chrome 58からはCNが非推奨化
    - https://rms.ne.jp/digital-certificate-news/chrome-deprecates_subject-cn-matching
    - https://www.chromestatus.com/feature/4981025180483584
- Firefox: 
    - Firefox 48からはCNが非推奨化（ソースは上記リンクを参照）
- Apple
    - https://support.apple.com/ja-jp/HT210176
    - CNは今後信頼されなくなる。



SANが必須になったことから、CSR申請時に指定されたCNをデフォルトでSANにコピーするという処理はどこの証明書業者でもやっており、例えば`CN=www.example.com`でCSR要求をすると、SANには`www.example.com`と`example.com`が追記されてくるといった仕様であることが多い（このようにwwwなしのFQDNをSANに追加することで、`https://example.com`でもアクセスできるようにすることを2way機能と呼ぶこともある）。各証明書業者ごとによってどのようにSANに自動登録されるかは違いがあり、例えば[ここ](https://help.sakura.ad.jp/206209181/#ac02)などによくまとまっている。

なお、証明書業者の中には、「マルチドメインサポート」の有無で価格が異なっているものがあるが、これは１つのFQDNだけを指定させることをユーザーに許可するか、複数のFQDNを含ませることをユーザーに許可するか？という証明書業者の中でのメニューの違いにすぎない。技術的には100個近いFQDNをSANに追加して１つの証明書で運用しても問題ない。

# ワイルドカード証明書

もともとは、ワイルドカード（&lowast;)を利用して、CN=&lowast;.example.comのように書けるようにしていたのがワイルドカード証明書である。しかし、上記のとおりSANが必須になった今、「１つのドメインしか利用者に指定させない」＋「そのドメインのFQDNをワイルドカードで指定可能」である証明書をワイルドカード証明書と呼んでいることが多い。広義の意味では先述の通り、その１つのワイルドカード指定したFQDNは必ずSANに登録されるので、「マルチドメインワイルドカード証明書」と呼んでもいいのかもしれないが、1つのドメインだけ利用者が指定可能というところを意図するために「マルチドメイン」という言葉を敢えて抜いているのだと思われる。

# マルチドメイン・ワイルドカード証明書
複数ドメインが指定できて、なおかつその中でワイルドカードを利用しているのであれば、狭義の意味でマルチドメイン・ワイルドカード証明書と呼んでもいいだろう。
以下はYahoo!Japanでの例。SANにワイルドカードが利用されている。

<img width="617" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/a316d239-95bb-e367-8a7a-72e48d3c30ae.png">
<img width="616" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/9353c682-c23b-ef6b-d87f-8a2ee630fad0.png">