クライアントサイトのSSL証明書を更新したところ、https://www.example.com でアクセスするとブラウザに「この接続ではプライバシーが保護されません」というエラーが出てしまいました。

原因は、SSL証明書の申請時に コモンネーム（CN）に www. を付けなかった こと。仕様としては正しい挙動だったのですが、つい「example.com で申請すれば www.example.com も自動的にカバーされるだろう」と思い込んでいたのが失敗でした。

結局、証明書を買い直して再設定することになりました。同じミスをする人を減らすため、

  • カラフルボックスでアルファSSLを購入・設定する正しい手順
  • 失敗の原因となったSAN（Subject Alternative Name）とデュアルアクセスの仕様
  • 関連知識としてDV/OV/EVや認証局の選び方、Let's Encryptとの違い
  • www.ありなしの統一リダイレクト

をまとめておきます。

    1. SSL証明書の基礎知識

    DV / OV / EV の違い

    SSL証明書には認証レベルが3種類あります。価格差は主にこの審査の厳しさによるもので、通信の暗号化強度はどれも同じです。

    認証レベル 略称 審査内容 組織（O）欄 価格帯（年） 発行時間
    ドメイン認証 DV ドメイン所有確認のみ 空欄 無料〜数千円 数分〜数時間
    組織認証 OV 企業実在確認あり 会社名 数万円 数日
    拡張認証 EV 厳格な企業審査 会社名 数万〜十数万円 1週間前後

    ブラウザのアドレスバーに表示される鍵マーク（🔒）はどのレベルでも同じです。EVだけ昔は緑のバーになっていましたが、現在の主要ブラウザではこの差別化表示は廃止されています。

    サイトシールとは

    サイトシールは、SSL証明書が導入されていることを訪問者に視覚的に示すバッジ（画像）です。フッターなどに自分で設置するもので、自動的にどこかに表示されるわけではありません。

    シールをクリックすると認証局の検証ページに飛び、その証明書が本物であることを確認できる、という仕組み。

    ただ、現実的には ない方が普通 です。大手企業のサイトでも設置していないところが多く、「設置していること自体が安心感を与える」場面はEC・金融・士業など、フォームから個人情報を送るタイプのサイトに限られます。

    Let's Encrypt（無料）との違い

    項目 Let's Encrypt 有料SSL（DV）
    価格 無料 1,000円〜
    暗号化強度 同等 同等
    認証レベル DVのみ DV/OV/EV選択可
    有効期限 90日（自動更新必須） 1年
    サイトシール なし あり（プランによる）
    賠償保証 なし あり
    サポート なし あり

    セキュリティ面では多くの同等。フォームも会員機能もない情報サイトであれば、Let's Encryptで十分というのが正直なところです。

    それでも有料SSLが選ばれる理由は次のようなものです。

    • クライアントの「うちは有料のSSLをかけている」という説明責任

    クライアント案件で「有料SSLを使ってほしい」と言われた場合、それは技術的合理性ではなく心理的合理性の話なので、議論せず素直に従う方が早いです。

    2. 認証局（CA）の選び方

    アルファSSL = GlobalSign のOEM

    カラフルボックスで販売されている「アルファSSL」は、実体としてはGlobalSign nv-sa（ベルギー）が発行するDV証明書です。証明書の発行元（issuer）を見ると以下のように表示されます。

    issuer = C = BE, O = GlobalSign nv-sa, CN = GlobalSign GCC R6 AlphaSSL CA 2025

    カラフルボックスがOEM販売しているだけで、実体のCAは世界大手のGlobalSignです。

    主要なDV認証局の比較

    項目 アルファSSL（GlobalSign） JPRS Let's Encrypt
    運営 GlobalSign nv-sa（ベルギー） Japan Registry Services（日本） ISRG（米国・非営利）
    ブランド 世界大手 国内最大手（.jp管理機関） 完全無料
    価格（年） 1,320円〜 数千円 無料
    有効期限 1年 1年 90日
    自動更新 あり あり あり（要設定）

    技術的な優劣はなく、管理のしやすさとコストで選ぶのが実際的です。カラフルボックスを使っているなら、管理画面から一括管理できるアルファSSLが最も手間がかかりません。

    3. SAN（Subject Alternative Name）とは

    ここからが今回のミスの核心です。

    SAN = サブジェクト代替名

    SANは Subject Alternative Name（サブジェクト代替名） の略で、X.509証明書の拡張フィールドの一つです。一つの証明書で複数のドメイン名をカバーするために使います。

    証明書の中身（イメージ）
├─ Subject (CN): www.example.com         ← 主体名（昔の主役）
└─ Subject Alternative Name:              ← 現在の主役
   ├─ DNS: www.example.com
   └─ DNS: example.com

    重要：現代のブラウザはCNを見ない

    ここを誤解している人が多いのですが、Chrome 58以降など主要ブラウザは、CN（Common Name）を多くの無視してSANのみを参照する仕様になっています。

    つまり、

    • CN=example.com だけが書かれていて、SANに www.example.com がない
    • → ブラウザで www.example.com にアクセスすると NET::ERR_CERT_COMMON_NAME_INVALID エラー

    これが今回のミスの正体でした。

    4. www.ありなしと「デュアルアクセス」の仕組み

    www.は本質的に「サブドメイン」

    www.example.com の www. 部分は、技術的にはサブドメインです。mail.example.com や blog.example.com と同じ階層にあり、ルートドメイン example.com とは別の名前空間として扱われます。

    ただ、「Webサイト＝www.」という慣習が長く続いたため、多くのブラウザやDNSが www.ありなしを実質的に同じサイトとして扱うように振る舞います。

    SEO上の扱い

    www.の有無による機能的な違いはありません。Googleもどちらでも同じサイトとして扱います。ただし両方アクセス可能なまま放置すると重複コンテンツ扱いになる可能性があるため、.htaccessなどでどちらかに301リダイレクトして統一するのが標準的なSEO対策です。

    アルファSSLの「デュアルアクセス」仕様

    ここがカラフルボックス（GlobalSign系）の重要な仕様です。マニュアルから引用します。

    「www.」のサブドメインの場合のみ「www.example.com」と「example.com」の両方の証明書になります。
    コモンネームを「example.com」で申請した場合は「example.com」のみの証明書となるのでご注意ください。

    つまり、

    申請時のCN 結果
    example.com（wwwなし） example.com のみカバー
    www.example.com（www付き） 両方カバー（デュアルアクセス）

    「www.付きで申請すれば両方カバー」という非対称な仕様です。これを知らないと、私のように example.com で申請して www.example.com でエラーになります。

    5. カラフルボックスでアルファSSLを購入・設定する手順

    Step 1：購入

    カラフルボックスのマイページから、SSL証明書 → アルファSSL を購入。

    「ドメイン選択」画面では、対象ドメインを入力します。この画面の www. プレフィックス表示はColorfulBoxストア側のフォーマットであって、実際の証明書のCNを決めるものではありません。後のCSR入力画面で決定します。

    Step 2：CSR情報の入力（最重要）

    購入後、「今すぐ設定する」から発行申請ページに進みます。

    キー長:        新しい2,048ビットのキーを作成します
コモンネーム:   www.example.com         ← ★ここに必ず「www.」を付ける
市区町村:      XXXX-ku, XXXX City
都道府県:      XXXX
国:           JP（日本）
会社名:       Your Company Inc.
会社の部署:    IT Department
メールアドレス: admin@example.com

    コモンネームに www. を付けるのが今回の核心です。example.com（wwwなし）で申請するとwww.example.com でアクセスしたときに証明書エラーになります。

    Step 3：承認メールの送信先選択

    次の画面でドメイン認証方式を選びます。メール認証が一般的です。

    承認メールの送信先を以下から選択する画面が出ます。

    ○ admin@www.example.com         ← ✗ これを選ぶとデュアルアクセス無効
○ administrator@www.example.com
○ hostmaster@www.example.com
○ postmaster@www.example.com
○ webmaster@www.example.com
● admin@example.com             ← ◎ 必ず「www.」が付いていない方を選ぶ
○ administrator@example.com
○ hostmaster@example.com
○ postmaster@example.com
○ webmaster@example.com

    これもマニュアルに明記されています。

    アルファSSL証明書でのデュアルアクセスを有効にするには、「証明書承認メールの送信先メールアドレス」に「www.」が付いていないメールアドレスを選択する必要があります。

    Step 4：承認メールの確認

    選択したメールアドレス宛に GlobalSign から「アルファSSL／承認手続きのお知らせ」というメールが届きます。本文中の承認URLをクリックし、表示された画面で「承認する」を押します。

    コモンネーム: www.example.com    ← www付きになっていることを確認

    Step 5：発行完了メールを待つ

    承認後、数分〜数時間で「[カラフルボックス]SSL証明書の発行が完了しました」というメールが届きます。これでCSR/秘密鍵/中間証明書のセットが揃います。

    6. cPanelで証明書をインストールする

    カラフルボックスのマイページから、新しく発行された証明書を取得し、cPanelに貼り付けます。

    コピー元と貼り付け先の対応

    カラフルボックス側 cPanel側のフィールド
    証明書（pem形式） 証明書: (CRT)
    プライベートキー 秘密キー (KEY)
    中間証明書 証明機関バンドル: (CABUNDLE)

    cPanel の セキュリティ → SSL/TLS → SSLサイトを管理します から、対象ドメインの「新しいサイトの証明書を使用する」を選び、上記3つを貼り付けて「証明書のインストール」をクリック。

    -----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- までヘッダー・フッター行を含めて丸ごとコピーするのがポイントです。

    インストール成功の確認

    cPanelの SSL/TLS Manager 画面で、対象ドメインの錠アイコンが緑になり、www付き・wwwなしの両方が緑であれば成功です。

    ✓ example.com        （緑）
✓ www.example.com    （緑）

    7. .htaccessでwww.ありなしを統一する

    SEO上の重複コンテンツを防ぐため、.htaccessで301リダイレクトを設定します。

    www. → wwwなしに統一する場合

    # HTTPS Redirect
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# www → non-www リダイレクト
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

    wwwなし → www.に統一する場合

    # HTTPS Redirect
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# non-www → www リダイレクト
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

    WordPressの場合、.htaccess の # BEGIN WordPress ブロックの外側（直前）に追記します。WordPress側の wp_rewrite がブロックを書き換えるため、内側に書くと消える可能性があるためです。

    重要な注意点

    リダイレクトはあくまでHTTPSで接続が確立した後に動作します。HTTPS接続時の証明書検証は最初に行われるため、証明書にwwwが含まれていない状態でwww付きにアクセスすると、リダイレクトが動く前にエラーが出ます。

    つまり、証明書側でwwwをカバーしておく必要が前提条件です。これが今回のミスの教訓でもあります。

    8. トラブル時の確認方法（opensslコマンド）

    「証明書にwwwが含まれているか」を確認したいときは、ターミナル（macOS標準のopensslでOK、cPanelのターミナル機能でも可）で以下を実行します。

    SAN（Subject Alternative Name）の確認

    echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

    期待する出力（デュアルアクセス対応の場合）

    X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

    両方のDNS名が出ていれば成功です。

    より詳細な情報が欲しい場合

    echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

    出力例：

    subject=CN = www.example.com
issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign GCC R6 AlphaSSL CA 2025
notBefore=May  7 06:07:07 2026 GMT
notAfter=Nov 22 06:07:07 2026 GMT
X509v3 Subject Alternative Name:
    DNS:www.example.com, DNS:example.com
    • subject → 主体名（CN）
    • issuer → 発行元
    • notBefore / notAfter → 有効期間
    • X509v3 Subject Alternative Name → SAN

    ブラウザの錠マーク → 「証明書を表示」からも同様の情報が見られますが、コマンドラインの方がSANを正確に確認しやすいのでおすすめです。

    9. まとめ：チェックリスト

    カラフルボックスでアルファSSLを設定する際の要点を、チェックリストにまとめます。

    購入・申請時

    • アルファSSLを購入
    • CSR情報入力時、コモンネームに www. を付ける（例：www.example.com）
    • 認証方式は「メール認証」を選択
    • 承認メールの送信先は www. が付いていないアドレス（例：admin@example.com）を選択
    • 受信用メールアドレス（admin@example.com等）が事前に作成・受信可能になっている

    承認・インストール時

    • 承認メールの本文でコモンネームが www. 付きになっていることを確認
    • 承認URLをクリックして承認
    • 発行完了メールが届いたら、CRT/KEY/CABUNDLE の3点をcPanelに貼り付け
    • cPanel SSL/TLS Manager で対象ドメインと www.付きが両方緑マークになることを確認

    動作確認

    • https://example.com で🔒マークが表示される
    • https://www.example.com で🔒マークが表示される（エラーが出ない）
    • openssl コマンドで SAN に両方が含まれていることを確認
    • .htaccess でどちらかに301リダイレクトされる

    おわりに

    今回の失敗の本質は、「業界標準の挙動」と「OEM販売側の仕様」が必ずしも一致しないことを見落としていたことでした。GlobalSignが直接販売している場合は、CN=example.com で申請しても自動的にwwwがSANに付与されることが多いのですが、カラフルボックス経由のアルファSSLではCN指定がそのまま結果になる仕様です。

    「コモンネームには www. を付ける」「承認メールは www.なしを選ぶ」——この2点を覚えておけば、私と同じミスは避けられます。同じ落とし穴にハマる人が一人でも減れば幸いです。

    参考リンク