サーバー証明書のつくりかたと、その原理

サーバー証明書」とやらを作る羽目になって困ってる人がときどきいる。こんなの分からないよう、できないよう、とか言って。特に、「証明書が失効しているよ」という報告を突然うけて、誰かがそれの対処をしなくちゃ、ということがありがち。なんで証明書ってのは永久に使えないんだ!と逆切れする人もいる。

同じようなことをけっこう色々な場面で説明してきた気がするが、こういう所にもメモを残してしまえば誰かの役に立つかもしれないと思うので、書きます。てっとり早く作るためのコマンドの叩き方だけじゃなくて、原理も含めて説明してみます。技術的にすごく正確に書く自信はないんだけど、ちょっと調べてみる限り、類似の記事がなぜかネット上にあまり見つからない(チラシみたいなページなら多いんだけど)ので、じゃあやってみようかなあと。

自分用に管理しているメモも、ネタをこうやって公開したらもう捨ててしまえるし。

ここでは、Apacheというウェブサーバーに設置するためのサーバー証明書のことに絞って説明していきます。別に他のシステムでも本質は変わらないんだけど、個々のシステムにあわせて何通りもやり方を確認するのはめんどくさいのです。でも、最終的な設置場所とか設置フォーマット以外のことは、どれも共通ですよ。

ウェブサーバーに入れて使うときに、特に「SSLサーバー証明書」って呼ぶことがあるみたいですね。別に呼び方はどっちでもいいと思うけど。

サーバー証明書には暗号化の「鍵」が入っている

ひとことで説明してみるなら、電子証明書サーバー証明書を含む一般的な呼び方)っていうのは、「これこれこうこう」という何かしらの(ほんとに何でもいいです)内容と、「確かにこの通りだよ!」という誰かのお墨付きがセットになったデータです。

サーバー証明書っていうのは、上の電子証明書のつくりかたを原則として、さらに一定の決まった方式に従って作られているやつです。X.509ってのがその方式の名前です。多分ね。

ウェブサイトのサーバー証明書は、クライアント(つまりウェブサーバーにアクセスする人々)と暗号化通信をするときに必要なものです。https:// で始まるURLのことですね。サーバー証明書の中の「これこれこうこう」という内容には、暗号化に必要な鍵情報も入っているんです。しかも、その鍵情報は、あとで言う「誰か」によって、確かなものだと認定されている。だからクライアントは安心してそのウェブサーバーと暗号化通信をエンジョイできる… こんなストーリーです。

暗号化通信ができたとしても、それだけで充分ではないです。その相手が実はニセモノだったらあまり意味ないですね。暗号化通信さえしているんなら大丈夫だろう、と思って、ニセの銀行サイトに大事なパスワードを打ち込んじゃう、なんてことも起こりえます。なので、「これこれこうこう」の中には、暗号化のための鍵情報だけではなくて、相手の名前やサーバーのFQDN(www.kirinwiki.comとかそういう名前のこと)なんかも入っていて、クライアントにとって充分に信用できる情報であるために努力がされています。この内容も、同じく「誰か」によって確かさが保証されています。

サーバー証明書には「電子署名」がついている

クライアントがサーバー証明書の内容を信用する根拠は、その証明書の中に書かれた「これこれこうこう」の中身によることももちろんですが、それにくっついている「お墨付き」が何より重要なものです。このお墨付きは正しくは「電子署名」というデータです。これがくっついているとなぜ電子証明書は信用できるものとみなせるのでしょうか。

思い切って単純化すると、電子署名というのは一種のチェックサムです。チェックサムなら分かりますよね。クレジットカード番号の下何ケタはチェックサムで、数字をいじりながら足し算していくとその数に一致するからこいつは正当なカード番号だ、とかそういうのが確かめられるやつです。電子署名のケタ数はむちゃくちゃ大きいですが、しかもこれを計算する方法は普通のチェックサムよりずっと複雑なものですが、まあチェックサムと理解してもそんなに外した話ではないと思います。

この電子署名という名前の“チェックサム”を計算するには、「これこれこうこう」という何らかの内容そのものと、お墨付きを与えようとしている「誰か」がもっている「秘密のデータ」、この二つを材料として作ることと決まっています。電子署名は、この「秘密のデータ」がないと作ることができないわけ。つまり、その「誰か」とやらが、「これこれこうこう」の内容をよく確認して、しかるのちに、自分の秘密のデータをおもむろに取り出し、おごそかに電子署名をつくるわけです。そういう情報も、サーバー証明書にはくっついている。

ここでいう「よく確認する」というのは、本当に人間がよく確認するということです。人間がその「これこれこうこう」という内容を見て、この内容が事実と一致すること、申込みをした担当者に電話が通じること、そもそも会社が本当に存在すること、そういったことなどをきっちり責任を持って調べます。これが、サーバー証明書に有効期間が設定されていたり、サーバー証明書の作成に料金がかかったりすることの理由です。内容の検証のために人間が実際に働く必要があるのだから、カネがかかります。また、検証された内容も、ある程度時間がたったら、また改めて検証しなおさないといけないですよね。

ここまで書くと「誰か」ってのが何なのか見当もつくでしょうが、それは後述。

電子署名の原理についてもう少し

さて、あるクライアントは、あるウェブサーバーと暗号化通信をしようとして、同サーバーからまずサーバー証明書を(自動的に)入手します。これを見て、今まさに通信をはじめようとしているサーバーの素性が明らかなかことを(特にFQDNがアクセスしたいURL中のものと一致することを)確認し、また、電子署名も見て、これが正当なお墨付きを持っていることを確認し、そこではじめて安心して当該サーバーと暗号化通信をはじめるわけです。

ところで、電子署名を作った人は、「秘密のデータ」を使ってそれを作りました。それを確認しようとするクライアントは、もちろんその「秘密のデータ」が何かを知りません。電子署名が「チェックサム」みたいなものだとしたら、当然、クライアント側でもその検算ができるのでないと、電子署名が正しいものなのかどうかがそもそも誰にも分からないですね。ここらへん、どうなっているんでしょう。

これは、「公開鍵と秘密鍵」という技術を使うことで実現しています。このペアになる鍵データには面白い特徴があり、秘密鍵を使って暗号化したデータは公開鍵を使わないと復号できない、ということを実現しています。逆に、公開鍵を使って暗号化したデータは、秘密鍵を使わないと復号できません。同一の鍵データを使ってでは、暗号化と復号の両方をできないんですね。面白く、また不思議な話です。

ここからの詳細を少しすっ飛ばしていきなり次のことを言うのですが、電子署名を作るときには誰かの秘密鍵、それの検証(検算)をするときは、その秘密鍵に対応する公開鍵を使うことになっているんです。電子署名を作ることそのものは、秘密鍵をもつ「誰か」にしかできないんだけど、それが確かであることを知るのは、公開鍵を知っている人にならだれでも可能です。

秘密鍵は決して他人にバラしてはいけないものなんですが、「公開鍵」という名前だけあって、こっちのほうは誰にも公開してしまってよいものなんです。それでもちゃんと暗号は成り立つようにできているんです。

なるほど、じゃあ認証局が作った電子署名を検証するには、その認証局の公開鍵を手に入れればいいというわけだ。僕らはみんなの(特に電子署名を作った「誰か」の)公開鍵をどうやって入手すればいいのかな?

公開鍵は、これもまた「電子証明書」の中に入っているものなんですよ。

電子証明書の「数珠つなぎ」

電子証明書の「チェーン」って見出しにしたかったけど、別に技術用語のつもりじゃないことを強調したかったので、いっそ「数珠つなぎ」で。

電子署名をつくる「誰か」のことを、そろそろ正しく「認証局(CA)」って呼ぶことにします。別に国の機関みたいなものじゃなくて、単に電子署名をつくる権利を任されている誰かのことです。

今までのことを整理して、次のようなことが言えます。

電子証明書をつくるために、認証局による電子署名が要る。その電子署名を検証するには、認証局の公開鍵が要る。その公開鍵は、電子証明書の中から得られる。

すいません、すこし意地悪な書き方をしました。より正しくは、

●あるサーバー用の電子証明書をつくるために、認証局による電子署名が要る。その電子署名を検証するには、認証局の公開鍵が要る。その公開鍵は、認証局電子証明書の中から得られる。

です。登場する電子証明書が二種類あるのがミソです。

認証局電子証明書は、(後に言う中間CAの場合、)これも通信しようとしているウェブサーバーから渡されるはずです。この場合、クライアントははじめに電子証明書を二枚受け取ります。その後、一枚目の電子証明書(サーバーのもの)の内容を、二枚目の電子証明書認証局のもの)に含まれる公開鍵を使って検証し、そこでやっと安心してサーバーと暗号化通信をすることになるわけです。

じゃあ、その「認証局の証明書」とやらは、どうして信用していいんでしょう。

それは、その認証局の証明書も、より上位の「誰か」にお墨付きをもらっていますから、全く同じような方法でそれを検証すればいいんです。上位の「誰か」の証明書を入手しましょう。

じゃあ、その上位の「誰か」とやらを信用していい根拠は? そいつの証明書に誰がお墨付きを与えるの?

なにやらキリがないですね。この、証明書のお墨付きの「数珠つなぎ」構造は、どこで止まるんでしょう。すべての電子証明書に、根っこから信用を与えるのは誰でしょう。

ルート証明書

答えは、お使いのウェブブラウザに内蔵されている、ルート証明書というものにあります。インターネットエクスローラ(たとえばIE11)なら、[インターネットオプション]→[コンテンツ]→[証明書]→[信頼されたルート機関]から一覧できますし、Firefox(バージョン30)なら、[オプション]→[詳細]→[証明書]→[証明書を表示]→[認証局証明書]から一覧できます。

ウェブブラウザは、これら数十種類の認証局電子証明書ルート証明書)のことは無条件で信用するという風に設定されています。なので、電子証明書の数珠つなぎを上に上にたどっていったとき、自分の知っているルート証明書のどれかに突き当ったら、もとになったサーバー証明書をやっと信用する、というルールになっているわけです。

どれでも適当なルート証明書を取り上げて調べると、その証明書の署名をしているのは、そのルート認証局自身という風になっています。つまりその証明書は「俺様の正しさを保証するのは、この俺様自身だ」と主張しています。こういう構造になっている、ある意味手抜きなサーバー証明書のことを俗に「オレオレ証明書」と呼んだりしますが、ルート証明書オレオレ証明書の本質的な違いは、世界中のウェブブラウザからの無条件の信用を勝ち得ているか、という一点に尽きるでしょう。ルート証明書は偉大な勝ち組オレオレ証明書です。

個人的に知りたいのは、ルート証明書がウェブブラウザに収録してもらえると、その認証機関は晴れて認証局ビジネスが始められるんですよね。ある意味、利権って感じだよね。これの選定ってどういう決まりがあるんだろう。よく知らないんだ…

いや、上の段の話はおいといて、ウェブブラウザによって、またそのバージョンによって、収録されているルート証明書は少しずつ違います。昔のブラウザとか、携帯電話のブラウザで一部のウェブサイトとまともに暗号化通信ができないときがあるのは、これって必要とされるルート証明書(数珠つなぎの終点にあたる証明書)が入っているかどうかに依存するからです。

ひとつ、ついでの話。認証局電子証明書には、署名を検証するための公開鍵が入っているのですが、サーバー証明書にも公開鍵が入っています。じつはこれらの内容はほとんど同じ仕組みです。サーバー証明書は、何かの署名をするための公開鍵を持っているわけではなくて、クライアントと暗号化通信をするためにそれを使います。ウェブサーバーとウェブクライアントの間の暗号化通信にも、公開鍵と秘密鍵という技術を使っているんです。

ここまでのまとめ・結局やるべきことは

サーバー証明書の使われ方、検証のされ方について説明してきました。(思ったよりずいぶん長くなったな…)これらを踏まえて、結局のところ、ウェブサーバーを立ち上げて、https:// でまともな暗号化通信ができるようになるには、担当者は何をしたらいいんでしょう、というところをまとめます。

サーバー証明書に入れるための、公開鍵と秘密鍵を作る

サーバーで使うための、公開鍵と秘密鍵のペア(鍵ペアともいいます)を、まず新しく作ります。公開鍵は、あとでサーバー証明書ができあがったとき、それに搭載される予定のものです。秘密鍵サーバー証明書には入りませんし、認証局に申し込むときにも渡しません。自分ひとりで厳重に管理しましょう。
これらは、他の用途で使ったものを使いまわしたりはせず、いちいち新しく作り直すのが普通です。

opensslというコマンドを使って作ります。簡単です。

「これこれこうこう」という情報を入力したデータをつくる

標準的なサーバー証明書には、どういう属性を設定すべきなのかが決められています。opensslコマンドを使って、これのためのウィザード機能を実行することができます。聞かれたことにポチポチ回答するたけでできあがります。簡単です。

データをまとめて、認証局に「電子署名してください」と提出する

上の「これこれこうこう」という情報を入力する時に、opensslは鍵ペアの情報も受け取ります。ですから、ウィザードが終了したら、この提出用データも同時に完成しています。簡単です。

この提出するデータを「証明書要求」とも呼びます。

データをどういう申込みルートで提出するのか、その他の申請フォームはあるのか、など、そういったことは、実際に電子署名を申し込む認証局のルールに従うことになるでしょう。ここらへんは、コンピュータ的な話じゃなくて、事務手続きですね。たぶん簡単です。

できあがった電子証明書を受け取る

申請を完了して、お金とかも払ったら、やがて、電子証明書サーバー証明書)という名前のデータが届きます。認証局の誰かが、おごそかに電子署名をつけ加えてくれたやつです。別に自分たちが何をするわけでもなく、簡単です。

ウェブサーバーに設置する

を、ウェブサーバーの決められた場所に置きます。ルート証明書は、ウェブブラウザが持っているのだから、ここに置く必要はありません。

簡単です。

でも、手順を全部通して眺めてみると、なんだか難しそうに見えるのも確かですね。原理がわかっていて、何が必要で、ひとつひとつが何のための手順なのかが理解できれば、別に詳細な手順メモがなくても割と大丈夫なものですよ。

opensslを使った、実際の手順例

上の手順は、実際にどういう操作で行うのかを見ていきます。

opensslが使えるコンピュータにログイン

まずは、opensslがインストールされた手近なUnix系コンピュータにログインします。LinuxMacなら、たいていの場合はopensslが入ってると思います。Windowsには普通は入ってないんですけど、それ用のバイナリもあるみたいなので、探してインストールしてみてもいいですね。

どの環境で作っても、できるデータには違いがないです。

鍵ペアをつくる

公開鍵と秘密鍵の鍵ペアを作ります。RSAという方式の鍵にするのが普通です。鍵には長さという概念があり、これが充分に長いものでないと、最近は安全ではないとされています。2048bit長を使えばよいでしょう。

手初めに、まず openssl genrsa とでも叩いてみましょう。ここらへんは、手順に関係ないイタズラです。

$ openssl genrsa
Generating RSA private key, 1024 bit long modulus
...++++++
...................................++++++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDO7OtI4Ip33lENaUSgMGpgI9USnMlg6FxXahCTJInPZ27OwpmQ
aLnA1THJEmBMDyXV9Jp3M9DL1gS9uoK17znuz+jfcwxRdYALymn15Y07Rbe6tQHa
(中略)
MnVU5T/YHqZqeYPcZ3sT8aIsz/jPnw2iOC8Yw0UjyBM=
-----END RSA PRIVATE KEY-----

画面上に、作られた鍵ペア情報がダラダラ表示されました。この中に、公開鍵と秘密鍵をつくるために必要な情報がすべて含まれています。BEGINという行からENDという行までが正味の部分です。Base64エンコードされているんですが、別に知らなくてもよいです。コピペもできる、英数字の並びとして表現されているところが特徴です。

何度も同じコマンドを叩いてみましょう。そのたびに、違う情報がが出力されます。乱数をもとに作っていますから、二度と同じものはできないのです。この環境では、鍵長を指定しないときのデフォルト値は1024のようですね。

次は、本当に使うための鍵ペアを作ってみましょう。鍵長と出力先ファイル名を指定します。

$ openssl genrsa -out my.key 2048
Generating RSA private key, 2048 bit long modulus
...........................................................+++
.............+++
e is 65537 (0x10001)

my.key というファイルに鍵ペアが格納されました。適当なテキストエディタで眺めてみるとよいでしょう。

これを使うと一旦決めたなら、それ以降、このファイルを厳重に管理しましょう。万一盗まれてしまうと、これを使って通信の機密性が確保できなくなってしまいます。また、このファイルを紛失してしまったら、これをもとにして作られたサーバー証明書が全く役に立ちません。

このファイル自体のことを、一般に「秘密鍵」と呼ぶことも多いです。

おまけ・鍵ファイルにパスフレーズをかける

鍵ファイルにパスワード(パスフレーズ)をつけて暗号化しておくこともできます。(暗号化のための鍵データをさらに暗号化する、というのは不思議な感じですが。)これなら、万一このファイルを盗まれてしまっても、パスワードを知らないかぎり実際の鍵ペア情報にはアクセスできませんから、より安全になるでしょう。(ただし、後述のウェブサーバーにこのファイルを設置したら、サーバーを起動するたびにパスワードを入力しなくてはいけなくなりますから、程度によって使い分けを考えましょう。)

鍵ペアを新規生成するときに、たとえば -des3 というオプションを加えるとそれができます。

$ openssl genrsa -des3 -out my.key 2048
Enter pass phrase for my.key:(ここでパスワードを入力させられる)
Verifying - Enter pass phrase for k.key:(確認入力)

パスワードを忘れると、二度とこのファイルの中の鍵ペアにはアクセスできません。注意しましょう。

または、すでにある鍵ペアファイル(my.key)について、新しくパスワードつきの鍵ペア(new.key)に変換することもできます。

$ openssl rsa -in my.key -des3 -out new.key
(このあと同様にパスワード入力)

逆に、パスワードつきの鍵ペアがあって、それをパスワードなしに戻したいときは、下のようにします。ファイル名の例は適当ですよ。

$ openssl rsa -in new.key -out my.key
(ここで元の鍵ペアにアクセスするためのパスワードを入力)

証明書要求データをつくる

サーバー証明書には、主に「FQDN」と「公開鍵」の情報が入っていることが必要です。(X.509的には、FQDNのことを「common name」というようですが。)証明書要求データも、これらの情報を含むものになるはずです。

まずはデタラメな証明書要求というのを作ってみましょう。my.keyという鍵ペアを使って、my.reqという証明書要求データをつくるときのコマンドは、下のとおりです。

$ openssl req -new -key my.key -out my.req

この後、ウィザードが開始します。証明したい内容をいろいろと聞かれます。でもまずは、全部デフォルト値で済ませてみましょう。ひたすら[Enter]キーを連打しちゃえばよいです。できあがるデータはデタラメなものになりますが、証明書要求を何度作ったり消したりしても、別に誰にも迷惑はかかりません。

my.reqができましたか。できたら適当なエディタで中身を見てみるとよいですが、バイナリデータ(のBase64表現)として格納されており、あまり目で見て意味のある内容が確認できません。これを視認用に整形してくれるコマンドは下の通りです。

$ openssl req -in my.req -text -noout

下のような出力がされましたか。

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=XX, L=Default City, O=Default Company Ltd
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d2:02:ee:7e:5c:c9:d8:57:bc:ce:67:c7:33:c9:
                    (中略)
                    d9:de:6c:8b:6b:82:4d:25:8d
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha1WithRSAEncryption
         1c:8e:69:1e:3c:03:d8:94:bf:10:3c:1c:e0:08:b2:fc:4e:ce:
         (中略)
         bf:65

見るべきは、subject: の行と、public-key: の入ったブロックです。subjectの内容は、今回は、デフォルト値だけで作られたデタラメのものです。public-key は、この証明書を入手した人は、このサーバー証明書の持ち主(subjectの内容の相手)と、この公開鍵を使って通信してほしいということをあらわしています。

(ここに出てくるSignature Algorhithmのあたりのデータも一応「電子署名」なんですが、これはサーバー証明書電子署名とは違います。)

まともな証明書要求にするためには、さきに[Enter]を連打した一連の質問のうち、少なくとも Common Name 属性を真面目に入力しましょう。そこだけまともに(例えば www.mydomain.com)入力すると、subject: の行は下のように変化します。

Subject: C=XX, L=Default City, O=Default Company Ltd, CN=www.mydomain.com

CNがCommon Name のことです。もちろん、その他の属性を入力してあることが結局は必要なんですが、こんな感じに「証明」したい内容をここに盛り込んでいくのがやるべきことです。本番用のデータを作るときにどの属性を入力しておくことが必要かは、個々の「認証局」が明確に指定しているでしょうから、それに従ってください。

認証局から、電子証明書を受け取る

ここはもう、受け取るだけです。ナントカ.crtという名前でファイルが手元に届くでしょう。中身は、たぶんやっぱりBase64形式のバイナリファイルです。テキストエディタで覗くだけでは、詳しい内容はわかりません。

たとえば、受け取った証明書ファイルがserver.crtだったら、下のようなコマンドで内容を視認してみるとよいでしょう。

$ openssl x509 -in server.crt -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 102 (0x66)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: (認証局の素性にあたる情報)
        Validity
            Not Before: Dec 23 23:56:41 2013 GMT
            Not After : Dec 23 23:56:41 2014 GMT
        Subject: (サーバーの素性にあたる情報)
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:76:22:a0:f0:73:fd:14:56:86:da:2f:29:0a:
                    (中略)
                    dc:12:2b:fa:8a:3f:bd:6d:bb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                D4:70:95:1C:AC:0B:A8:83:C7:62:59:38:A8:59:79:A0:4B:7B:01:71
            X509v3 Authority Key Identifier:
                keyid:D4:70:95:1C:AC:0B:A8:83:C7:62:59:38:A8:59:79:A0:4B:7B:01:71

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         44:05:61:a4:f8:f9:6f:7d:72:e3:20:db:b1:43:53:bd:45:87:
        (中略)
         8c:9b

Issuerが、この証明書に署名をつけた認証局が誰かをあらわす情報です。Subjectは、証明書要求を作ったときと同じ情報が入っているはずです。

Validityのあたりを見ると、このサーバー証明書はいつからいつまで有効なのかが分かります。

Publick-Keyのあたりが、このサーバーと通信するときに使わせたい、公開鍵の情報です。

そして、Signature Algorithmのあたりが、認証局に作ってもらった電子署名の部分です。

ここらへんの情報は、ウェブブラウザで適当なhttpsのサイトにアクセスして、アドレス欄に現れる鍵マークなんかをクリックして探してみると見られる内容と同じです。だから、サーバー内に置いた、まさしくこの証明書データがクライアントに渡って、それが素性の確認に使われているんだということがわかりますね。

中間CA証明書を入手する

中間CA証明書は、必要なら、たいていは認証局のサイトのわかりやすいところからダウンロードできるようになっているはずです。これも、ナントカ.crt という拡張子のはず。

それぞれのファイルを、Apacheが指定する場所に配置する

配置すべきファイルがそろいました。秘密鍵ファイル、電子証明書ファイル、中間CA証明書ファイル(あれば)です。

Linuxディストリビューションによって少しずつ標準的な配置場所は違いますが、最近のCentOSの場合だと、

です。スーパーユーザーでないとアクセスできない場所なので注意しましょう。特に秘密鍵ファイルは、ファイル所有者(つまりroot)しかアクセス権がないようにしておきましょう。(chmod 600 とかで)

CentOSyumコマンドを使ってApacheを入れたとき、SSL設定のための設定ファイルは、

/etc/httpd/conf.d/ssl.conf

です。この中身のうち下の三行を直しましょう。

SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
  • 一行目が、サーバー証明書の場所。
  • 二行目が、秘密鍵の場所。
  • 三行目が、中間CA証明書の場所。必要なければ、行頭に#をつけて無効化したままでよい。

全部設置と設定が終わったら、Apacheを再起動ね。

# service httpd restart

長い話になった

今度はちゃんと、有効期限が切れる前に証明書を更新しといてよね。