カラフルボックスのアルファSSL購入・設定ガイド｜www問題とSAN対応の落とし穴

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

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

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

カラフルボックスでアルファSSLを購入・設定する正しい手順
失敗の原因となったSAN（Subject Alternative Name）とデュアルアクセスの仕様
関連知識としてDV/OV/EVや認証局の選び方、Let's Encrypt（無料SSL）との違い
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 OEM）	グローバルサインクイック認証SSL	JPRS
運営	GlobalSign nv-sa （ベルギー）	GlobalSign nv-sa （ベルギー）	Japan Registry Services （日本）
ブランド位置づけ	GlobalSign のOEM廉価版	GlobalSign 直販	国内最大手（.jp管理機関）
サイトシール	なし	あり（GlobalSignロゴ）	あり（プランによる）
価格（年）	1,320円〜	21,780円〜	数千円〜
有効期限	1年	1年	1年
自動更新	あり	あり	あり

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

なお、アルファSSL とクイック認証SSL はどちらも同じGlobalSignが発行するDV証明書で、暗号化強度・認証レベル・SEO評価はまったく同じです。約16倍の価格差は次の3点によるものです。

ブランド表記：クイック認証SSLは証明書情報や契約書類に「GlobalSign」名が出る。アルファSSLは「AlphaSSL」というOEMブランド名になる
サイトシール：クイック認証SSLはGlobalSignロゴ入り公式シールが提供される。アルファSSLはシールなし
保証・サポート：クイック認証SSLは保証額・サポート窓口ともに手厚い

「うちはGlobalSignのSSLを入れている」と対外的に説明したい、あるいはサイトフッターにシールを表示したい場合はクイック認証SSL、実利だけで十分ならばアルファ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. 導入後もブラウザで「保護されていない通信」が出る場合

証明書を正しく導入したはずなのに、自分のブラウザだけ「保護されていない通信」と表示され続けることがあります。実際に別案件で遭遇したので、原因と対処をまとめておきます。

症状

cPanel上では対象ドメイン・www.付きの両方が緑マーク
opensslで確認するとSAN両方入り、有効期限も正常
curl -I http://example.com/でHTTP→HTTPSの301リダイレクトも正常
WordPress「設定 → 一般」も両方https://
DevTools ConsoleにMixed Content警告なし
しかしChromeだけ「保護されていない通信」と表示される

原因

Chromeのセキュリティ判定がプロセス内メモリに保持されていたのが原因でした。

SSL導入前にそのドメインへアクセスしていた場合、Chromeは「このサイトのセキュリティ状態」を記憶しており、後から証明書が正しく整っても、その判定は次回プロセス起動までメモリ上に持ち越されるという現象です。

判別方法

「自分だけの問題」か「本当にサイトの問題」かを切り分けます。

シークレットモードで開いてみる → 🔒で正常表示なら、Chrome側の記憶が原因確定
Safariなど他のブラウザで開いてみる → 🔒で正常表示なら同上
他のPCやスマホから開いてみる → 同上

他の環境で問題なければ、実サイトは完全に正常で訪問者への影響はゼロです。あくまで導入作業を行った開発者のChromeプロファイルだけの表示問題です。

解決策：Cmd + Q でChromeを完全終了

ウィンドウを閉じるだけでは不十分です。Chromeは複数プロセスで動いており、メモリ内のセキュリティ判定はプロセス終了までクリアされません。

macOS：Cmd + Q
Windows：タスクトレイまで含めて完全終了、またはタスクマネージャーからChromeプロセスを終了

タブを閉じても、ウィンドウを閉じても、メニューの「Chromeを終了」でないと意味がありません。プロセスごと終了するのがポイントです。

それでも消えない場合の追加手順

まれに再起動でも解消しないケースは、以下を順に試します。

HSTS キャッシュから削除
chrome://net-internals/#hsts をアドレスバーに入力 → 「Delete domain security policies」に対象ドメインを入力 → Delete
サイトデータの削除
chrome://settings/content/all から対象ドメインを検索して削除
Service Worker のクリア
DevTools → Application → Service Workers → Unregister、続いて Storage → Clear site data

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

カラフルボックスでアルファ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 で🔒マークが表示される（エラーが出ない）
シークレットモードでも https://example.com が🔒で表示される（自分のブラウザキャッシュに騙されないため）
.htaccess でどちらかに301リダイレクトされる

おわりに

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

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