ECC版SSL証明書インストール体験記その4

02.08.13 / 未分類 / Author: aico / Comments: (0)

では、いよいよ発行されたECC証明書をインストールしましょう！

実はECC版SSL証明書は現在、ブラウザ・OSによっては対応していないものも多いので、
対応していないものはRSAの証明書を読むように、ECCとRSAのハイブリッド構成をすることが出来ます。

そしてなんと、ECCの証明書を申請するとRSAの証明書も一緒にもらうことが出来ます(ベリサインさん太っ腹！)

なので今回はECCとRSAのハイブリッド構成を組みつつ証明書のインストールを行います！

まずはベリサインのサイトで中間証明書を確認しましょう。

発行されたCRT、中間証明書、秘密鍵は必ず対になっている必要があります。
対になっていないとエラーになってしまいます。。

小悪魔ブログは最初、中間証明書間違いをしてエラーになってしまってました。。
(みなさんもキヲツケテ！)

———————————-
– グローバル・サーバID EV (ECC対応版) 専用中間CA証明書
https://www.verisign.co.jp/repository/intermediate/server/ev_pro_ecc.html

– グローバル・サーバID EV (RSA用) 中間CA証明書
https://www.verisign.co.jp/repository/intermediate/server/ev_pro.html
———————————-

それぞれECC用とRSA用とあるので注意です！

すべての鍵がでそろったところでサーバに証明書を設置しましょう。

鍵はECCとRSA、それぞれ準備する必要がありますよ。

———————————-

# cd /usr/local/ssl/
# vim ecc_ssl.crt
# vim rsa_ssl.crt
– CRTを設置

# vim ecc_ssl.key
# vim rsa_ssl.key
– 秘密鍵を設置

# vim ecc_ca.crt
# vim rsa_ca.crt
– 中間証明書を設置

———————————-

設置が完了した所で、鍵の置き場はここだよ〜というのをconfファイルに書き込みます。

ここで！apacheの設定のときに、httpd.confに↓この文章をアンコメントしましたよねっ

———————————-

# cd /usr/local/apache2.4/conf/
# less httpd.conf
—————
478 Include conf/extra/httpd-ssl.conf
—————

# cd conf/extra/
# vim httpd-ssl.conf

————————————————-

なので鍵の置き場はhttpd.confではなく、httpd-ssl.confに記入しますっ

————-

48: SSLProtocol all -SSLv2
53: SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!ADH
66: SSLHonorCipherOrder off
89: ServerName kmonos.jp:443

108: SSLCertificateFile “/usr/local/ssl/ecc_ssl.crt”
109: SSLCertificateFile “/usr/local/ssl/rsa_ssl.crt”

119: SSLCertificateKeyFile “/usr/local/ssl/ecc_ssl.key”
120: SSLCertificateKeyFile “/usr/local/ssl/rsa_ssl.key”

131: SSLCertificateChainFile “/usr/local/ssl/ecc_ca.crt”
132: SSLCertificateChainFile “/usr/local/ssl/rsa_ca.crt”

————-

confファイルに書き込むSSLCertificateFile 等は通常は一つですが、
ハイブリッド構成の時はECCとRSAの2つを記入して行きます。

書き終わりましたか？では、最後にapacheの再起動を行いましょう〜！

————-

# cd /usr/local/apache2.4/bin
# ./apachectl stop
# ./apachectl start

————-

これにて設定完了ですっ(お疲れ様でした〜 ! )

実は、ECC証明書のお話をベリサインさんから頂いたあと、

こあくまには難しすぎたので色んな人にほぼ色々やってもらっちゃってました笑
(こあくま周りでモタモタしていただけでした。。すみません。。)

でも、みなさん口を揃えて言っていた、「設定の方法はRSAの時とそんなにかわらないから難しくない。
でも事例がなさすぎて果たしてこれで合ってるのか!?がわからないのが大変。」…は
こあくまもブログを書くにあたり実際に勉強してみて、すごく実感しました。。

また、実はECC証明書、まだ対応が進んでおらず、
OSやブラウザによってはエラーが出てしまったりもするそう。

※今後の対応状況最新版は下記のURLをご確認ください！
——————-
https://www.verisign.co.jp/ssl/about/client-ecc-dsa.html
——————-

でも、CSRの作成の時やインストール完了時は本当に感動！
より短い鍵のECCが広まる為にも、はやく対応が進むといいですねっ

ECC版SSL証明書インストール体験記その3

31.07.13 / 未分類 / Author: aico / Comments: (0)

さて、それでは申請のためにECC版SSL証明書のCSRを作成しましょう！

まずは秘密鍵を作成します。

——————–

# /usr/local/openssl/bin/openssl ecparam -out privatekey.key -name prime256v1 -genkey
# ls -la
————
-rw-r–r– 1 root root 302 4月 22 16:43 privatekey.key
————

——————–

次に、さっき作った秘密鍵を使用してCSRを作成します！
今回はグローバルサーバID EVSSLなので、証明書に記載される社名を日本語表記にしちゃいます♪

# /usr/local/openssl/bin/openssl req -new -utf8 -key privatekey.key -out request.csr
– 社名が日本語表記のCSRを作成
– 英語表記の場合は-utf8を抜く

最後に作成したCSRの中身を確認してみましょう！

——————–

# openssl req -in request.csr -text

——————–

実際にCSRを作成して確認してみると分かりますが、本当に鍵の長さが短いです…！

(↑ECCがこんなかんじで〜)
(↓RSAがこんなかんじ！)

ちなみに今回の申請ではベリサインのマネージドPKI for SSLで行いました。
(申請中も色々ありました…)

ちなみに、ベリサインでは現在、テスト用のECC版SSL証明書の提供が行われています！

ECC版SSL証明書インストール体験記その2

26.07.13 / 未分類 / Author: aico / Comments: (0)

ECC版SSL証明書ではopensslとapacheの最新版をインストールする必要があります！

では早速opensslの1.0.1eをインストールしましょう！

opensslをインストールするディレクトリに移動して、wgetで1.0.1eのファイルを取得し、展開します。

————————–

# cd /usr/local/src/
# wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
# tar xzvf openssl-1.0.1e.tar.gz

————————–

# cd openssl-1.0.1e
# ./config –prefix=/usr/local/openssl shared

————————–

人間が分かりやすいプログラミング言語で書かれたソースコードを、
PCが理解できて実行可能なコード(オブジェクトコード)にコンパイルして、インストールを実行です！

————————–

# make
# make install

————————–

# echo ‘/usr/local/openssl/lib’ > /etc/ld.so.conf.d/openssl.conf
# ldconfig

————————–

ちゃんと1.0.1eがインストールできてるかな？(ドキドキ)確認しますっ

————————–

# cd /usr/local/openssl/bin
# ls -la
– opensslがあることを確認
# /usr/local/openssl/bin/openssl version
————
OpenSSL 1.0.1e 11 Feb 2013
————

————————–

これにてopensslのインストールは完了っ！次にapacheの2.4.4をインストールしましょう〜！

apacheのインストールでは、APR、APR-utilも一緒にインストールする必要があります。
opensslと同じようにwgetでファイルの取得を行いましょう！

————————–

# cd /usr/local/src/

# wget http://ftp.jaist.ac.jp/pub/apache/httpd/httpd-2.4.4.tar.gz
# wget http://ftp.jaist.ac.jp/pub/apache/apr/apr-1.4.6.tar.gz
# wget http://ftp.jaist.ac.jp/pub/apache/apr/apr-util-1.5.1.tar.gz
————————–

————————–

# tar xvfz apr-1.4.6.tar.gz
# cd apr-1.4.6
# ./configure –prefix=/usr/local/apr/
# make
# make install

————————–

# cd /usr/local/src/
# tar xvfz apr-util-1.5.1.tar.gz
# cd apr-util-1.5.1
# ./configure –prefix=/usr/local/apr-util/ –with-apr=/usr/local/apr/
# make
# make install

————————–

そして最後にapache！

————————–

# cd /usr/local/src/
# tar xvof httpd-2.4.4.tar.gz
# cd httpd-2.4.4
# ./configure –prefix=/usr/local/apache2.4 –with-apr=/usr/local/apr –with-apr-util=/usr/local/apr-util –enable-so –enable-ssl=shared –with-ssl=/usr/local/openssl
# make
# make install

————————–

apacheの設定ファイル、httpd.confの中身を確認します

————————–

# less -N /usr/local/apache2.4/conf/httpd.conf/

– 以下のようになっていることを確認
——————
31 ServerRoot “/usr/local/apache2.4”
87 LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
126 LoadModule ssl_module modules/mod_ssl.so
187 ServerName localhost:80
211 DocumentRoot “/usr/local/apache2.4/htdocs”
478 Include conf/extra/httpd-ssl.conf
——————

————————–

最後にapacheの起動を行って完了ですっ

————————–

# /usr/local/apache2.4/bin/apachectl start

————————–

ECC版SSL証明書インストール体験記その1

24.07.13 / 未分類 / Author: aico / Comments: (0)

実は小悪魔ブログ、ECC対応版SSLサーバ証明書の導入を行いました。
商用での導入は小悪魔ブログとディレクターズのkmonos.jpが世界初！なのです〜(どんどんぱふぱふ〜！)

ではみなさん…小悪魔ブログのURLの鍵マークを押して♪

詳細を表示を押してみてっ♪

ECCと書かれているのを確認して頂けましたでしょうかー！(どやっ)

しかし…
導入までは山有り谷有りありました…

今日はECC対応版SSLサーバ証明書の導入体験日記ですっ

ところでECC対応版SSLサーバ証明書とは？？？？
これまでのRSA版SSLサーバ証明書とはどう違うのでしょう？

RSA暗号はマサチューセッツ工科大学の3人の研究者によって開発されました。
「RSA」という名前はその3人の頭文字から名付けられています。

RSA暗号の世界はちょっぴり特殊で、「ある数までいくと0に戻る世界」を使用します。

んん？なにその世界？となった方も多いと思いますが、
例えば時計。
時計は12時は0時、13時は1時…と
12までいくと0に戻る世界を利用していますよね。

また、12まで行くと0に戻るということは、
12で割った数の「余り」を計算するのと同じことにもなります。

RSAでは、鍵を作る時に2つの素数を使用します。
素数とは1と自分でしか割り切ることのできない数のこと。

RSAでは2つの素数を用いてワンペアの公開鍵・秘密鍵を作ります。

「2つの素数を掛けた数」が公開鍵の一部として公開されますが、
鍵のもととなる2つの素数は公開せず隠します。

鍵の作り方は後日紹介する(かも?)として…
RSA暗号の解読の難しさは「素因数分解の難しさ」に由来します。

ある数を2つの素数に分けることを素因数分解といいます。
実は、効率的に素因数分解する方法はまだ見つかっていないのです。

RSA暗号では公開鍵から秘密鍵を見つけようとすると、
2つの素数を掛けた数である600桁以上(2048bit)の数を素因数分解し、
公開鍵・秘密鍵を作る為に使った2つの素数を割り出す必要があります。

コンピュータを使えば簡単に素因数分解できるのでは？と思ってしまいますが、
現在、素因数分解に成功している世界記録の数は232桁(768bit)。
さらに鍵を長くすれば長くするほど素因数分解は難しくなり暗号化強度も増していきます。

ECC暗号は楕円曲線と呼ばれる数式を使った公開鍵暗号方式です。

楕円曲線暗号の仕組みについては文系の小悪魔にはすっごーーーーーーーーーーーーーーーーーーーーーく難しいのですが、

楕円曲線暗号は世界の数学史上最大の難問と呼ばれている「フェルマーの最終定理」を解く鍵にもなったりもしています。

RSAは768bitを解読するのに300台のPCで3年かかったものの、
少しずつ解読を効率的に行なう手法が発見されつつありますが、
楕円曲線暗号は未だ効率的に解析するアルゴリズムは存在していません。

そのため、より短い鍵長での暗号化をすることが可能となり、
RSAの1024bitとECCの160bitはほぼ同等の暗号化強度を持っています。

ベリサインホワイトペーパーで挿絵を描きました

05.10.12 / 未分類 / Author: aico / Comments: (2)

こあくまからお知らせです！

日本ベリサインさんではホワイトペーパーと呼ばれる
SSLについての技術情報などの資料を公開しているのですが、

今回、『簡単にわかる暗号の歴史』についてのホワイトペーパーで挿絵を描かせていただきました！

今回はnewキャラクターのネズミくんとニャンコが登場してます♪

現在、ベリサインのwebサイトにて公開されているのでぜひぜひダウンロードして見てください〜
ダウンロードはコチラから→ベリサインホワイトペーパー
簡単なアンケートが必要なようなのでコチラもご協力よろしくお願いします♪

DESとは？

28.05.12 / 未分類 / Author: aico / Comments: (0)

今日は暗号のお話です。DES暗号について調べてみました！

DESは暗号の方式(アルゴリズム)を広く公開した商用の暗号です。

暗号はそれまでは軍事用として使われていました。
そのため、誰がどのような暗号を使用しているか、アルゴリズム自体もトップシークレットでした。
しかし戦後、コンピュータを多くの人が使うようになると、
企業間での商取引等、インターネット上でやり取りするデータの暗号化が必要となりました。

しかし、異なる企業間でやり取りをする際、お互いが別々の暗号方式を使っていては
情報のやりとりができません。そこで、IBMのHorst Feistelによって、
「鍵」を秘密にし、「暗号アルゴリズム」は公開するDESが、
暗号モジュールに関するセキュリティ要件の仕様を規定する米国連邦
標準規格(FIPS 140)に採用されました。

では、DESの仕組みを見てみましょう！

コンピュータでは、電気が通っていない状態を「０」、通っている状態を「１」とする
２進数で情報を置き換えてやり取りしています。
なのでDESによる暗号化でも２進数に変換して考えます。

DESの暗号化の流れはこのようになっています。

では、実際に暗号化の様子を見てみましょう！
まず、暗号化されていない文章(平文)を2進数にして64bitごとにブロック化します。

英数字なら1ブロック8文字、全角日本語なら1ブロック4文字となります。

そのブロックを「初期転置」と呼ばれるbitの入れ替えを行います。

DESでは暗号アルゴリズムが公開されているので、どのように入れ替えるかも公開されおり、
表の番号順に並び替えを行います。
先ほど64bitごとに区切りましたが、58bit目が1文字目、50bit目が2文字目…と並び替えます。
よく見ると縦の列を横の列に並び替えているのがわかります。

入れ替えたものを32bitずつ、LとRに2つに分けます。
ここで、Rのコピーを作ります。

次に、Rの方だけに拡大型転置を行い再び入れ替えを行います。

初期転置の表と同じく拡大転置の表も公開されています。
32bit目が1文字目、1bit目が2文字目です。
列の5・6bit目と次の列の1・2bit目の数字が同じになるようになっていて、
入れ替えると32bitから48bitに増えるようになっているので「拡大」転置です。

拡大型転置を行ったRと作成した内部鍵で排他的論理和をとります。
…排他的論理和とは？
その前にまず、内部鍵を作成しましょう！
DESの流れの絵でも書いた通り、DESでは16回内部鍵との排他的論理和をとるため、
内部鍵も16個作成します。

DESは共通鍵暗号方式の１つです。
暗号をやり取りするもの同士で共通の鍵を持って暗号化・複合を行います。

まず、データをやりとりするもの同士で56bitの鍵を決めます。

この時の鍵は56bit＋エラー検出に利用する符号パリティ8bitで64bitになっています。
「暗号アルゴリズム」を公開するかわりに「鍵」は秘密になっているため、
鍵は誰にも知られずにやりとりをする必要があります。

そのデータに縮約型転置を行います。
転置前は64bitで57bit目を1文字目に、49bit目を2文字目に入れ替えを行います。
入れ替えが行われると64bitから56bitに縮約され、これを28bitずつ左右に分けてそれぞれCとDとします。

次に循環シフトを行います。
1番前の数字を順番に一番後ろに移動させるので循環シフトです。
循環シフトの表には、どれだけ循環させるのかが書かれています。
16個の鍵を作るので表の数字は16個ありますね。
1つ目の鍵の時は1のようなので1文字目だけ後ろに循環させます。

CとD、それぞれに循環シフトを行った後CとDを合体させ、
縮約型転置を行って、入れ替えて48bitにします。

同じように2回目、3回目と循環シフトを行い、
それぞれに縮約型転置を行って1つの鍵から16個の内部鍵を作ります。

これで内部鍵が完成です！

では、拡大型転置を行ったRと内部鍵で排他的論理和をとりましょう。

排他的論理和とは、１と１なら０、０と１なら１、０と０なら０というように、
どちらか一方が１ならば１を、それ以外(どちらも１、どちらも０)なら０を返す論理演算のことをいいます。
「どちらか一方が１」なら１です。
Rと内部鍵の1つ目で排他的論理和をとります。

排他的論理和をとったRを6bitごとに8つにわけます。
今度は圧縮換字変換Sに基づいて圧縮換字変換というものを行います。
6bitを4bitに圧縮。表から代替する数字を選び換字変換します。

表はこのように8つあります。これを8つにわけた6bitにそれぞれ使用します。

まず、1bit目と6bit目を合体させて行数を選びます。

この場合、0と0なので０。2進数の0は10進数でも0なので0行目になります。
次に、真ん中の4bitを使って何文字目かを決めます。
この場合、2進数の1010は10進数では10になるので10文字目。
なので0行目の10文字目を選びます。

ここでは6になるので、10進数で6は2進数では0110となるので、010100は0110に換字変換されます。
おなじようにそれぞれ8つの6bitを4bitに換字変換していきます。

次に再び転置を行い、

ここで最初に分けたLとこれまでの作業を行ったRの排他的論理和をとります。

ここで、最初のRをコピーしたものをL1、Lと排他的論理和をとったものをR1として1回目は終了です。

同じように2回目、3回目…とL16、R16になるまで16回繰り返します。

いよいよL16、R16となったらLとRを合体させて最終転置を行います。

最終転置の表は、初期転置で行ったものと反対になっているのがわかります。

最終転置ができたら暗号化終了です！

Baseline Requirementとは？

09.05.12 / 未分類 / Author: aico / Comments: (0)

2011年に偽造証明書が発行されるという事件がありました。

発行されてしまったのはComodo社とDigiNotar社の偽造証明書。
Comodo社のケースではGmailやskypeなどの偽造証明書が、
DigiNotar社のケースではなんと531件の偽造証明書が発行されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。
どうしてそのような事件が起きてしまったのでしょう？
まずComodo社のケースから見てみましょう。

認証局(CA)は、
申請者の情報を確認し発行する前の審査を行う登録局(RA)と
審査の結果を受けて証明書発行のみ行う発行局(IA)に分かれます。
1つの認証局が両方を行う場合もありますが、
Comodo社では事件の起きた2011年時点では登録局の業務を外部に委託しており、

Comodo社では認証を簡素化するために自動発行を行っていたため、
登録局がハッキングされ偽造証明書が発行されてしまいました。

一方、DigiNotar社では、ComodoHackerと名乗る人物が
DigiNotar社のシステムへのパスを不正に入手、
証明書を発行のための情報を得て偽造証明書を発行しました。

GoogleなどのWebブラウザには認証局が自ら署名して発行する
ルート証明書があらかじめ組み込まれています。
このルート証明書を使ってコンピュータはwebサイトに発行されている
証明書が正しいものなのか確認しています。

今回のケースでは偽造証明書は、ルート証明書が登録されているDigiNotar社の
証明書として不正に発行されてしまっていたため、信頼できる証明書として扱われてしまっていました。

なぜ偽造証明書に気づいたかというと、Google ChromeがGoogleのサイトのみ
各ページの証明書を発行するルート認証局の一覧を所持する機能をサポートしていたため、
偽のGmailのページにつけられたDigiNotarの証明書に対してセキュリティ警告したためでした。

それまでに実に531件もの偽造証明書が発行されてしまったため、
Google Chromeを始めとするWebブラウザベンダーによって
DigiNotar社のルート証明書がリストから削除されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。

実は、原則的には認証局は誰でも作ることが出来ます。

各認証局ごとに安全性への取り組みは異なりますが、
信頼できる証明書とは認証局が考える「PDCA」を遵守して発行される必要があります。

PとはPlan(企画・計画)。

認証局はそれぞれの証明書を発行する際の運用規定をまとめたCPSを制作し、
ホームページ上でまとめています。

DとはDo(実行)。

CPSに従って運用を行います。

CとはCheck(評価)。

定期的にセキュリティの脆弱性アセスメントを行い結果を監査報告します。
また、外部監査も行います。

AとはAction(改善・見直し) 。

セキュリティの促進やインシデント(問題)が起こった時のルールのドキュメント化などを行います。
ベリサインではこのようにCPSによって認証の運用規定を作成し、運用を行っています。

しかし、ComodoやDigiNotarの偽造証明書発行事件が起こってしまいました。
事件が起きた当時、業界全体での運用規定をまとめた文書の作成を行う議論が進んでいましたが、
この事件がおきたことで議論が加速し、
業界全体での運用規定をまとめた文書、Baseline Requirementが調印されることとなりました。

Baseline RequirementはCA Browser Forumによって制定されました。
Baseline Requirementは、それまでCPSによってそれぞれが定めていた運用規定を
業界でまとめた初の試みで、2012年の7月から発行されます。
ベリサインやジオトラスト、グローバルサインや、IEやsafari等の主要なCAとブラウザベンダーが
サインをしているため、Baseline Requirementに準拠しない場合は
ブラウザの信頼されるルート証明書から除外される可能性があります。

Baseline RequirementはベリサインのHPにて近日公開予定のようです。

常時SSLとは？

02.05.12 / 未分類 / Author: aico / Comments: (0)

先週、ベリサインさんでカンファレンスがあったので参加してきました！
その中で常時SSLとbaseline requirementについてもお話があったので、
自分でも調べてまとめてみました。

SSL証明書はこれまではログインの画面や、ネットでのショッピングの際に
選んだものが表示されるショッピングカートのページのみにつけられていました。
常時SSLとは、ログイン画面などだけではなく、
トップページ等ユーザが訪問する全てのページでHTTPS通信を行うようにすることです。

Firesheepなどwifi通信で暗号化されていないセッションを自動的に検出してcookieの
情報を読み取るツール等が出現したことが原因です。

cookieを使うと一度訪問したwebサイトにもう一度訪れた時に、
cookieの情報をもとにwebサイトはユーザを識別することが出来ます。

例えば、何回訪問したかといった情報や、ログイン情報を記憶し入力を省略したり、
見たページから好みに合いそうな商品や広告を表示することができます。

さらに、cookieにはセキュアcookieというものがあります。
セキュアcookieにすると受け渡しするのは暗号化されているhttps通信の時のみにすることができます。

Firesheepはカフェやホテル等、オープンなwifiを通じて
firesheepが登録しているサイトに、暗号化されていないhttp通信でログインしている
ユーザのcookieの情報を簡単に見ることが出来てしまいます。
さらに情報を見るだけではなくその情報を使ってなりすましてアクセスすることだって出来てしまうのです。

そのため全てのページにSSLをかけてhttps通信にすることで
情報を暗号化して守ろう！というのが常時SSLです。Firesheepは暗号化されていないセッションを検出するものなので
https通信にすることでcookieの情報を守ることができます。

すでに常時SSLを実装しているサイトとして、twitterやFacebook、Google等があります。
GoogleではGmailとGoogleAppのユーザ向けに、
Facebookでは選択可能になっていますが約2割のユーザが常時SSLを選択しています。

やりとりをする情報が重要なサイトやログインするユーザの多いサイトでは
セキュリティは常に意識して運営していきましょう！

SANsとは？ワイルドカード証明書とは？

13.04.12 / こあくまのSSL日記, 未分類 / Author: aico / Comments: (4)

社会人になってからあっという間に２週間がすぎました。
覚えることがいっぱいでなんだか毎日があっという間に過ぎていきます。

先日、VeriSignさんと打ち合わせがありました。
VeriSignさんとは何度かお会いしていますが、今回は社会人になって初めての打ち合わせ。
知らない言葉もたくさん出てきたので自分なりに調べてみました。

今回はSANsとワイルドカード証明書についてです。

普通、サーバ証明書はコモンネーム１つにつき、サーバ証明書を１枚申請します。

ワイルドカード証明書とSANsは１枚のサーバ証明書で複数のコモンネームへのSSL通信を可能にする方法です。

ワイルドカード証明書はコモンネームを、「*.usausa.usa」のように
アスタリスクをサブドメインに相当する階層に記載した形で申請します。
すると、ワイルドカード証明書は複数のサブドメインを使用しているサイトで
それぞれのコモンネームでサーバ証明書を取らなくても１枚のSSLサーバ証明書で
httpsアクセスを有効にします。
ただし、アスタリスク(＊)の後ろのドメイン名は同一である必要があるため、
たとえば、www.usausa.netのようにドメイン名が違うとまた別にSSLサーバ証明書を取得する
必要があります。
→現在ベリサインでは発行していません。

SANsはコモンネームをwww.usausa.usaで申請し、SANsにusausa.usaを登録すると、
１枚のサーバ証明書でwww.usausa.usaとusausa.usaの両方でhttps通信を有効にすることが出来ます。
SANsはワイルドカードとは異なり、SANsに登録すれば同一ドメイン名でなくてもSSLが有効になります。
→ベリサインでは2012年6月15日以降の申請からSANsフィールドを追加するそうです。