意外と知らないSSL証明書の話

初めまして。朝日ネットのhakuです。今回はわかるようでよくわからないSSL証明書について話してみたいと思います。

Protocol

HTTPとHTTPS

ウェブページのアドレスに必ず入るHTTPとHTTPSの違いは何でしょうか。

HTTPはHyper Text Transfer Protocolの頭文字ということはIT系に興味がある方なら常識とも言えるくらいですが、HTTPSのSがSecureの頭文字ということは意外と知らない方もいらっしゃいます。 そう、HTTPSはHyper Text Transfer Protocol Secureの略で、HTTPとは違って暗号化通信をします。 それではHTTPとHTTPSの違いは何でしょうか。 HTTPの場合は通信内容を横から盗み出したり改ざんされる恐れがあります。 しかしHTTPSの場合は、文字通りセキュリティ的に優れた暗号化通信です。現在の技術ではこの暗号化された通信を横から盗み出しても復号は現実的に不可能です。 HTTPSはすべての通信が暗号化される分、HTTP通信に比べてサーバが重くなります。 ちなみに、HTTPSはネットスケープコミュニケーションズで1994年自社のウェブブラウザであるネットスケープのために開発されたそうです。 そしてこれが銀行やカード決済のページ、ログインページなどの限られたところから使用し始めて、 今はお金や個人情報に関するページに限らず、接続先がHTTPSでないと大丈夫かなぁという不安を感じるくらい一般的に使われるようになっています。

ということで、HTTPS通信をするために必要な証明書について語りたいと思います。

SSLとTLS

まずはHTTPSの場合登場するSSLとTLS protocolについてです。HTTPSはSSL通信とも言いますが、SSLはSecure Sockets Layerの略で、TLSはTransport Layer Securityの略です。 それではこの二つの違いは何でしょうか。 結論から言いますと、同じだと思ってもいいです。TLSはSSLの後継プロトコルです。 SSL3.0の後からはTLS1.0に名前が変わりました。（SSLv3 → TLSv1 → TLSv1.1 → TLSv1.2 → TLSv1.3の順） しかし今でもIT業界でさえ最新のTLSよりSSLが一般的に通用する用語になっています。 証明書の場合もSSL証明書とはよく耳にしますが、TLS証明書とはなかなか馴染みがありません。

暗号化アルゴリズムのCipher Suite（暗号スイート）

SSL/TLSについてもう少し詳しく見てみると、暗号スイートというアルゴリズムの一覧があります。 クライアントとサーバがSSL通信を始める前のハンドシェイクに、この暗号スイートが含まれています。 クライアントはclient helloで持っている暗号スイートの一覧を送ります。 サーバはクライアントからもらった一覧から一つを選んで返します。 こうやって両者が合意して使う暗号スイート一つを決めます。

そして暗号スイートは優先順位があって、一般的には優先順位の上位から順に合意します。サーバはクライアントからもらった暗号スイート一覧の優先順位や自分が持っている暗号スイートの優先順位から共通する暗号スイートをクライアントに返します。 上の図は一つの例ですが、この図だとクライアントとサーバが持っている暗号スイートの中で、優先順位から共通する暗号スイートは「TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」です。

ここで疑問はクライアントとサーバで利用可能な暗号スイートはどう決まる？どうわかる？ですが、サーバ側の暗号スイートは証明書とウェブサーバの設定によって決まります。 そしてクライアント側はブラウザが持っています。例えばMSのIE9の場合は、TLSv1.1以上は対応できないため、TLSv1.0までの暗号スイートを持っています。 ということは最新バージョンのブラウザの対応ができない古いOSを使用している場合、脆弱性のある暗号スイート（復号ができてしまう）で繋がる恐れがあります。 こういうことを防ぐためにサーバ側で脆弱性のある暗号スイートを無効化することで回避することができます。

※主要ブラウザは2020年の前半までに（Chrome 1月、Firefox 3月、Safari 3月から）TLSv1.1以下は無効化するそうです。

※記事を読んで頂いた方からのご指摘により、「暗号化アルゴリズムのCipher Suite（暗号スイート）」の項目を一部修正しました（2020年03月27日）。

証明書の構成

SSL通信をする際にはクライアントのブラウザからサーバ証明書まで、ちゃんと認証されて繋がっているか（チェーン）を検証します。 これを理解するために、証明書のissuerとsubjectをわかる必要があります。issuerは発行者でsubjectは発行先です。 下では「i」がissuerで「s」がsubjectになります。

それではhttps://asahi-net.co.jpを例として見てみます。

ルート証明書

ルート証明書は最上位の認証局が発行している証明書です。最上位の認証局なので、自分で自分の身元を保証する形になります。 なので、issuer（発行者：GlobalSign¹ Root CA）とsubject（発行先：GlobalSign Root CA）は同じになります。 すべてのルート証明書は主要ブラウザには基本的に入っているので、クライアントがルート証明書を別途設置することはないです。 同じ意味でブラウザが勝手に補充してくれるのでサーバ側でルート証明書を用意する必要もないです。

中間証明書

中間証明書はブラウザが持っているルート証明書とサーバ証明書がチェーンになるような役割を果たします。 issuerのルート認証局がsubject（GlobalSign Organization Validation CA - SHA256 - G2）を認証します。

サーバ証明書

サーバ側に設置される証明書です。 issuer（GlobalSign Organization Validation CA - SHA256 - G2）がsubject（asahi-net.co.jp）を認証します。

クロスルート証明書

古いバージョンのブラウザは主要ブラウザにあるルート証明書がなかったりします。 こういう場合クロスルート証明書を使用してルート証明書とチェーンになるようにします。 中間証明書に古いルート証明書とチェーンできるルート証明書を出して中間証明書を2階層にします。このチェーンができるようにするルート証明書をクロスルート証明書と言います。 うちの顧客のほとんどはフィーチャーフォン（ガラケー）ユーザーだという場合はクロスルート証明書が必須となるでしょう。 ※上記の図はクロスルート証明書を理解しやすくするために作り出したものなので、実際のissuerとsubjectではありません。

認証別証明書の種類

自己署名証明書（通称：オレオレ証明書）

認証局の認証をもらっていない証明書です。証明書があるため暗号化されたSSL通信は行われますが、誰が発行した証明書かがわからない証明書のため、一般の企業で使われることはないです。もちろん自分で作ることも可能です。

DV証明書 ドメイン認証（DV: Domain Validation）

ドメインが存在すれば認証局からドメインの登録者を確認して発行する証明書です。

OV証明書 企業認証（OV: Organization Validation）

OVはドメインだけではなく、企業の実在を認証局で確認します。whoisから会社名や所在地などを確認し、実際ドメインの運営者にメールなどで確認を取ってから認証局から証明書が発行されます。

EV証明書（Extended Validation）

EVは最も審査が厳しい証明書です。その分価格も高いし、証明書が発行されるまで時間もかかります。でもアドレスバーに会社名と共に緑色で表示されてエンドユーザーには信頼度を高く評価されます。

認証別証明書の疑問

上で調べた証明書は暗号化も違うか気になりますが、結論から言いますと暗号化のレベルに変わりはありません。 どの証明書を使ってもSSL通信を行います。ただ認証局から種類によってどのくらい確認をするかの違いはあるので、エンドユーザーに与える信頼感は変わるかもしれません。

サービス別証明書の種類

証明書は基本１FQDNに１IP addressでした。 しかしIPv4アドレスは枯渇しつつあるのに、ウェブページの数は増える一方です。 この問題を解決するための証明書がワイルドカード証明書です。

ワイルドカード証明書

ワイルドカード証明書は「*」で「*」のところにどの文字が入っていても適用される証明書です。 例えば、asahi-net.co.jpというドメインにmail.asahi-net.co.jp、isp.asahi-net.co.jp、vne.asahi-net.co.jpというサブドメインがvhostとして動いているとします。 この場合、3つのFQDNsが*.asahi-net.co.jpという証明書でまとめることが可能です。

ここで注意すること！ 「*」はドメイン名の「.」前までです。「.」がその先にまたある場合は適用できません。またネイキッドドメインもダメです。

例）*.asahi-net.co.jpの場合

isp.asahi-net.co.jp OK

stage.isp.asahi-net.co.jp NG

asahi-net.co.jp NG

上の例でNGのFQDNも「*.asahi-net.co.jp」証明書にstage.isp.asahi-net.co.jpを入れたい場合は、stage-isp.asahi-net.co.jpで修正すれば適用されます。 ネイキッドドメインについては後述します。 え？うちで運用しているウェブページのドメインは同じじゃないけど…ワイルドカード証明書は使えないんじゃない？どうすればいい？という場合はマルチドメイン証明書Multi Domain Certificate（MDC）を使用すればいいです。

マルチドメイン証明書 （MDC）

マルチドメイン証明書は一つのコモンネームに複数のFQDNsを含めて利用することが可能です。 マルチドメイン証明書に含まれるFQDNsは通称Subject Alternative Names（SANs）と言います。 例えば、asahi-net.co.jpというコモンネームの証明書にasahi-net.or.jp、asahinet.com、stage.isp.asahi-net.netなどのSANを入れる形です。 この場合はasahinet.comのページでもstage.isp.asahi-net.netのページでも証明書を見るとasahi-net.co.jpの証明書だと表示されます。 そしてフィーチャーフォン（ガラケー）ユーザーからはコモンネームのサイトにしかアクセスできないというデメリットもあります。

プロトコル側の対応：SNI（Server Name Indication）

SNIはワイルドカードやマルチドメイン証明書とは少し異なって、ハンドシェイクをする際に、クライアントがどのホストにアクセスしたいかの情報を渡します。その情報をもらったサーバは該当するホストの証明書を使う方式です。サーバ側の証明書はホストごとに必要です。そしてSNIには問題点があります。ハンドシェイクはSSLの通信の前に行われるため、クライアントがどのホストにアクセスしようとしているかの情報は保護されていない状態のままだということです。これを利用してインターネット検閲をしている国もあるそうです。それと主要ブラウザではない古いブラウザではSNIをサポートしないので、フィーチャーフォン（ガラケー）ユーザーはSNIを使用しているサーバにはアクセス出来ません。

ネイキッドドメイン（Naked Domain）

証明書の種類ではないのですが、カテゴリーとしてここで記述した方がいいと思って書きます。 ネイキッドドメインとはwwwなどのホスト名なしで使われるドメインです。wwwのホストを使っているホームページは多いですが、asahi-net.co.jpのようにwwwのホストを使わないホームページもあります。認証局からコモンネームがasahi-net.co.jpの証明書を発行してもらったらwwwのホストネームだけは使用することができます。逆にwww.asahi-net.co.jpのコモンネームで発行してもらってもネイキッドドメインは使用することができます。 しかしネイキッドドメインはワイルドカードドメインには入りません。*.asahi-net.co.jpの証明書にasahi-net.co.jpを追加しても適用できません。

まとめ

以上、SSL通信をするための証明書について色々話してみましたがいかがでしたか？サービス提供側では証明書を効率的に利用し、ユーザー側に安定したサービスが提供できるように、ユーザー側では安全な通信をするための豆知識になっていたらなぁと思います。

採用情報

朝日ネットでは新卒採用・キャリア採用を行っております。

 

---

1. GlobalSign® 及び GlobalSign のロゴは、GMO グローバルサイン株式会社(GMO GlobalSign K.K.)の登録商標です。↩