NTPが同期しないのはなぜ? RTX1100が原因!

WEBサーバをWindows ServerからCentOSに乗せ替えたのを機に、ログの時間を正確に合わせようとNTPサーバを組んでみましたが・・・・
なぜが同期しません。なぜ?なぜ?
プロバイダはビジネスぷららなので、プロバイダの提供するNTPサーバを利用してみます。
http://biz.plala.or.jp/support/manu/index.html
プライマリは「ntp2.plala.or.jp」、セカンダリは「ntp1.plala.or.jp」となります。
しかし、ntpdateの詳細コマンドの実行結果でも「no server suitable for synchronization found」となります。

# ntpdate -d ntp2.plala.or.jp
12 Jul 23:40:50 ntpdate[8159]: ntpdate 4.2.2p1@1.1570-o Sat Dec 19 00:58:17 UTC 2009 (1)
Looking for host ntp2.plala.or.jp and service ntp
host found : ntp2.plala.or.jp
transmit(219.164.211.137)
transmit(219.164.211.137)
transmit(219.164.211.137)
transmit(219.164.211.137)
transmit(219.164.211.137)
219.164.211.137: Server dropped: no data
server 219.164.211.137, port 123
stratum 0, precision 0, leap 00, trust 000
refid [219.164.211.137], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 15:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 15:28:16.000
transmit timestamp: cfe5a7f6.24db4890 Mon, Jul 12 2010 23:40:54.143
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
12 Jul 23:40:55 ntpdate[8159]: no server suitable for synchronization found

いろいろと調べてみると、YAMAHAのRTX1100の設定が問題だとわかりました。
NTPサーバを公開するフィルタ/NTPサーバに接続するフィルタを教えてくださいhttp://www.rtpro.yamaha.co.jp/RT/FAQ//IP-Filter/public-ntp-server.html
なるほど!DNSと同じでUDP通信のNTPは戻りパケットはestablishedでは通過できないのか。
ということで、rejectの前に
ip filter 33 pass * 210.160.212.153-210.160.212.158 udp ntp ntp,1024-65535
を追加して、
pp select 1
ip pp secure filter in 11 12 13 14 15 16 21 22 23 24 25 31 32 33 34 100
INフィルタに定義を追加しました。
ふたたび・・・・・

# ntpdate -d ntp2.plala.or.jp
12 Jul 23:45:08 ntpdate[8172]: ntpdate 4.2.2p1@1.1570-o Sat Dec 19 00:58:17 UTC 2009 (1)
Looking for host ntp2.plala.or.jp and service ntp
host found : ntp2.plala.or.jp
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
server 219.164.211.137, port 123
stratum 4, precision -17, leap 00, trust 000
refid [219.164.211.137], delay 0.03940, dispersion 0.00006
transmitted 4, in filter 4
reference time: cfe5a88c.cf4080f9 Mon, Jul 12 2010 23:43:24.809
originate timestamp: cfe5a8e9.6788ca3e Mon, Jul 12 2010 23:44:57.404
transmit timestamp: cfe5a8f4.abc21187 Mon, Jul 12 2010 23:45:08.670
filter delay: 0.04099 0.03940 0.03972 0.03954
0.00000 0.00000 0.00000 0.00000
filter offset: -11.2734 -11.2734 -11.2736 -11.2734
0.000000 0.000000 0.000000 0.000000
delay 0.03940, dispersion 0.00006
offset -11.273424
12 Jul 23:45:08 ntpdate[8172]: step time server 219.164.211.137 offset -11.273424 sec

今度は「step time server 219.164.211.137 offset -11.273424 sec」にメッセージが変わったので、NTPサーバと通信できたようだ。
さらに、しばらく待って・・・

# ntpdate -d ntp2.plala.or.jp
13 Jul 00:05:15 ntpdate[8265]: ntpdate 4.2.2p1@1.1570-o Sat Dec 19 00:58:17 UTC 2009 (1)
Looking for host ntp2.plala.or.jp and service ntp
host found : ntp2.plala.or.jp
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
receive(219.164.211.137)
transmit(219.164.211.137)
server 219.164.211.137, port 123
stratum 4, precision -17, leap 00, trust 000
refid [219.164.211.137], delay 0.03911, dispersion 0.00008
transmitted 4, in filter 4
reference time: cfe5ac8f.106a8fc0 Tue, Jul 13 2010 0:00:31.064
originate timestamp: cfe5adab.ddec0b56 Tue, Jul 13 2010 0:05:15.866
transmit timestamp: cfe5adab.d5633482 Tue, Jul 13 2010 0:05:15.833
filter delay: 0.04726 0.03952 0.03952 0.03911
0.00000 0.00000 0.00000 0.00000
filter offset: 0.026731 0.026530 0.026451 0.026577
0.000000 0.000000 0.000000 0.000000
delay 0.03911, dispersion 0.00008
offset 0.026577
13 Jul 00:05:15 ntpdate[8265]: adjust time server 219.164.211.137 offset 0.026577 sec

adjust time server 219.164.211.137 offset 0.026577 sec
やった!!NTPが同期しましたよ。

グローバル固定IPアドレスは枯渇間近!?

今日帰って来たら自分の加入しているプロバイダ「ASAHIネット」から葉書が来ていました。
内容は・・・・
「固定IPアドレスサービス」ご利用料金改定のお知らせ
フレッツ・光プレミアム回線で固定IPアドレスサービスを利用する場合、月額費用1,050円のなかで無料で利用できましたので、私も随分お世話になりました。
しかし、9月利用分より月額840円がかかるようになります。と言っても、月額合計1,890円という業界最安値ラインではあるのですが・・・
今はすでに別サービスで固定IP8個を契約しているので必要ないので解約します!
今回の案内はどうも「NTT西日本限定」だったようなのですが、NTT東日本地区は先に値上げになっていたのかな?

おれおれ証明書(プライベート証明書) クライアント証明書編

CA構築編、サーバ証明書編、と続いたクライアント証明の実現方法ですが、いよいよ「クライアント証明書」編の始まりです。
ユーザディレクトリに移動します。
# cd /usr/local/ssl
秘密鍵を2048bitで作成します。
# openssl genrsa -out client.private.pem 2048


Generating RSA private key, 2048 bit long modulus
……………………………………………………………+++
….+++
e is 65537 (0x10001)


秘密鍵を使用して署名リクエスト(公開鍵)を作成します。クライアント(ユーザ)単位に適用する証明書なので、ユーザ名がわかる名前を付けます。
# openssl req -new -key client.private.pem -out admin.free-style.biz.pem


You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.

おれおれ証明書(プライベート証明書) サーバ証明書編

おれおれCA(プライベート認証局)が構築できたところで、「サーバ証明書」を作成していきます。いわゆる「ルート証明書」に当たるものです。
サーバ証明書の作成は、秘密鍵を作って、署名リクエストを作成して、CAに認証させるという手順を踏むのですが、CAを新しく作る手順の場合は、このCA作成のなかでほとんどの手順が終了してしまっています。
それではできている公開鍵が認証できるかどうか確認してみましょう。
# openssl verify /etc/pki/CA/cacert.pem


cacert.pem: /C=JP/ST=Tokyo/L=Shinagawa-ku/O=Fs DataCenter CA/CN=ca1.free-style.biz
error 18 at 0 depth lookup:self signed certificate
OK


SSL証明書用のユーザディレクトリを作成して、移動します。
# mkdir /usr/local/ssl
# cd /usr/local/ssl

クライアントに組み込むためのサーバ証明書を作成します。
# openssl x509 -inform pem -in /etc/pki/CA/cacert.pem -out ca1.free-style.biz.crt -outform der
これで終わりです。
というのもあんまりですので、別に証明書を作成して署名してみましょう。
証明書はユーザディレクトリに作成します。
# cd /usr/local/ssl
新しく秘密鍵を2048bitで生成します。
# openssl genrsa -out private.pem 2048


Generating RSA private key, 2048 bit long modulus
..+++
……………………..+++
e is 65537 (0x10001)


秘密鍵を使用して署名リクエスト(公開鍵)を作成します。
# openssl req -new -key private.pem -out request.pem


You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.

おれおれCA(プライベート認証局)構築編

CA(認証局)の定義ファイルだけ作成して、おれおれCAを作成する方法もあるようですが、今回はローカルのデフォルトCAを入れ替える方法で作成します。
OS:CentOS5.3
1.オリジナルCAの定義ファイルをバックアップします。
# cd /etc/pki/tls
# cp -a openssl.cnf openssl.cnf.org

2.定義ファイルをおれおれCA用に変更します。
# vi openssl.cnf


#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn’t
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd
# Uncomment out to enable OpenSSL configuration see config(3)
# openssl_conf = openssl_init
# To use this configuration file with the “-extfile” option of the
# “openssl x509” utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[openssl_init]
# Extra OBJECT IDENTIFIER info:
oid_section = new_oids
alg_section = algs
[ new_oids ]
# We can add new OIDs in here for use by any config aware application
# Add a simple OID like this:
# shortname=Long Object Identifier Name, 1.2.3.4
# Or use config file substitution like this:
# testoid2=OID2 LONG NAME, ${testoid1}.5.6, OTHER OID
[ algs ]
# Algorithm configuration options. Currently just fips_mode
fips_mode = no
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = ../../CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to ‘no’ to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Comment out the following two lines for the “traditional”
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
→クライアント証明書の標準の有効期間を「3652」日(10年)に変更します。
default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that 🙂
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the ‘anything’ policy
# At this point in time, you must list all acceptable ‘object’
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 1024
→標準の公開鍵長を「2048」bitに変更します。
default_md = sha1
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
# we use PrintableString+UTF8String mask so if pure ASCII texts are used
# the resulting certificates are compatible with Netscape
string_mask = MASK:0x2002
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = GB
→標準の国名を「JP」に変更します。
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Berkshire
→標準の都道府県名を「Tokyo」に変更します。(各自お好みで)
localityName = Locality Name (eg, city)
localityName_default = Newbury
→標準の都市名を「Shinagawa-ku」に変更します。(各自お好みで)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = My Company Ltd
→標準の組織名を「Fs DataCenter CA」に変更します。(各自お好みで)
# we can do this but it is not needed normally 🙂
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when ‘ca’ signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
→サーバ証明を「CA:TRUE」に変更します。
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
nsCertType = server, client, email, objsign
→サーバ証明の種類を追加します。「SSL サーバー認証」「SSL クライアント認証」「SMIME」「 署名」とりあえず全部入れます。
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape’s comment listbox.
#nsComment = “OpenSSL Generated Certificate”
→コメントアウトします。
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren’t
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
nsCertType = sslCA, emailCA
→コメントアウトを外します。
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where ‘obj’ is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape’s comment listbox.
nsComment = “OpenSSL Generated Certificate”
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren’t
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo


定義ファイルを保存します。
この定義ファイルを基にして新しいCAを構築します。
念のためオリジナルCAをバックアップします。
# cd /etc/pki
# mv CA CA.org
# cd /etc/pki/tls/misc/
# cp -a CA CA.org

設定ファイルを変更します。
# vi CA


DAYS=”-days 365″ # 1 year
→ルート証明書の有効期限を「DAYS=”-days 3652″ # 10 years」(10年)に変更します。
CADAYS=”-days 1095″ # 3 years
→CAの有効期限を「CADAYS=”-days 3652″ # 10 years」(10年)に変更します。


新しいCAを作成します。
# ./CA -newca


CA certificate filename (or enter to create)
→そのままEnterキー
Making CA certificate …
Generating a 2048 bit RSA private key
…………………+++
….+++
writing new private key to ‘../../CA/private/./cakey.pem’
Enter PEM pass phrase:
→秘密鍵のパスワードを入力します。
Verifying – Enter PEM pass phrase:
→秘密鍵のパスワードを再入力します。

メール暗号化はまだまだマイナー?

ちょうど仕事の案件でS/MIMEを使用することになったので、調べてみました。
私自身はMyDocomoで送られてくるこの画面・・・
メール電子署名付き
でおなじみのサイバートラストのS/MIME証明書「Sure Mail」を当てにしていたものの、問い合わせてみると、
「この商品は電子署名のみで暗号化していません」
なんですとーーーー!!!
確かに、電子署名と暗号化が同時に適用されたメールは
メール暗号化・電子署名付き
このようになります。(後で調べた結果ですが)
勝手に電子署名と暗号化が適用されていると思っていた自分がバカでしたが、単なるフィッシング対策だけのために大仰な仕組みを採用しているとは思ってもみなかった。
他のSSL証明書発行会社ではクライアントで使用するS/MIME証明書しか発行しておらず、今回サーバーからプログラムで実行するという条件では使えないものばかり。
やはりメール暗号化はマイナーな存在だ・・・・
結局、自己証明書で実現するしかなさそうだ!おれおれCA構築するぞ!

Google Analytics 携帯版 携帯端末だけ見たい!

前回の続き
カスタムレポートで携帯の端末別に表示できたものの、「7」や「XP」などPCからアクセスした「OSのバージョン」がやはり邪魔ですね・・・
ということで方法を調査してみました。
Google Analytics(グーグル アナリティクス) 携帯版
まずは端末名リストの下にある「アドバンス フィルタ」を試してみました。
Google Analytics (グーグル アナリティクス)携帯版
「OSのバージョン」に「XP」「Vista」「2000」を含まないとしてフィルタを適用します。
Google Analytics(グーグル アナリティクス) 携帯版
「7」は端末名にあるので外せませんが見れないことはありません。
ただ・・・・フィルタは1回限りということで、次回リンククリック時はリセットされてしまいます。毎回セットするのは・・・ダメですね。
Google Analytics (グーグル アナリティクス)携帯版
ということで、前回作成したカスタムレポートを編集してみます。
Google Analytics (グーグル アナリティクス)携帯版
気になるのは「ディメンション」の下の「サブディメンション」です。これどうやって使うんだろうか?
Google Analytics(グーグル アナリティクス) 携帯版
「OSのバージョン」を「サブディメンション」1階層目へ移動し、「モバイル」を「ディメンション」に、「月」を「サブディメンション」2階層目に、「週」を「サブディメンション」3階層目に、「日別」を「サブディメンション」4階層目にドラッグアンドドロップしました。
「レポートを保存」して表示すると・・・
Google Analytics(グーグル アナリティクス) 携帯版
最初の表示は「モバイル」かどうかのフラグ(「Yes」or「No」)になりました。
「Yes」(モバイル)のリンクをクリックすると・・・
Google Analytics(グーグル アナリティクス) 携帯版
「OSのバージョン」が表示されますが、上の階層でモバイルのみでフィルタがかかっていて希望通り!!ですね。
Google Analytics(グーグル アナリティクス) 携帯版
さらに、端末名のリンクをクリックすると端末別の「月」の集計数
Google Analytics(グーグル アナリティクス) 携帯版
「週」の集計数
Google Analytics(グーグル アナリティクス) 携帯版
「日別」の集計数と進みます。
「サブディメンション」は設定次第ではとても有意義な機能です。
最後に、一覧表形式ではなく、円グラフ形式にする方法を
Google Analytics(グーグル アナリティクス) 携帯版
表の右上に切り替え用のアイコンがあります。
Google Analytics(グーグル アナリティクス) 携帯版
通常は一番左になっていますが、左から2番目を選択すると、円グラフが見えます。
といっても、端末名が細分化しているので利用価値があるかどうかは別問題です。

「クロスルート」は「暗号アルゴリズムにおける2010年問題」を救うのか?

大袈裟なテーマですが、今プスプスと火種ができている状態です。おそらく今年の年末頃になるとマスコミでも取り上げられる問題になる可能性もあります。
「暗号アルゴリズムにおける2010年問題」の対応により「公開鍵長が2048bit以上」になる(2011年以降は2048bit証明書のみ発行される)と、例えばベリサインの「セキュア・サーバID」のルート証明書は「VeriSign Class 3 Primary CA – G5」を使用します。
しかし、このルート証明書は最近の端末にしか搭載されていないため、旧端末を救済するための方法として、ベリサインでは「クロスルート方式」が採用されています。
実際のサイト証明書までの証明階層構造を見てみましょう。
「セキュア・サーバID」公開鍵長1024bit
Class 3 Public Primary CA – G2
  Class 3 Secure Server 1024-bit CA – G2
    サイト証明書
1024bitではルート証明書は「Class 3 Public Primary CA – G2」となり、サイト証明書との間に中間証明書が入る3階層となります。
「セキュア・サーバID」公開鍵長2048bit対応端末
Class 3 Public Primary CA – G5
  Class 3 Secure Server CA – G3
    サイト証明書
2048bitの対応端末ではルート証明書は「Class 3 Public Primary CA – G5」に変更となり、サイト証明書との間に中間証明書が入る3階層となります。
「セキュア・サーバID」公開鍵長2048bit未対応端末
Class 3 Public Primary CA
  Class 3 Public Primary CA – G5
    Class 3 Secure Server CA – G3
      サイト証明書
2048bitのルート証明書「Class 3 Public Primary CA – G5」を搭載していない未対応端末では、最上位に「Class 3 Public Primary CA」を追加して4階層となります。「Class 3 Public Primary CA」はほとんどの旧端末に搭載されているので認証できることになります。これが「クロスルート方式」といわれる方法です。
しかし、携帯端末にルート証明書が搭載されていればOKかというと、話はそうは単純ではないのです。そもそも端末仕様として2048bit暗号を扱える端末(またはアプリケーション)なのかどうかが問題となるのです。
6月に入り問題となった、auのEZアプリ(BREW)向けサービスの一部の通信ができないという事象は、まさに2048bit暗号を扱えないアプリの問題でした。
https://www.verisign.co.jp/ssl/about/20100601.html
そのため、クロスルート方式であっても、今までのように旧端末もすべてカバーするとうわけには行きません。事実、2G機種や古いスマートフォン、一部の3G機種では対応できないことが発表されており、大幅に対応数が減っています。各社、3G機種のみを対象としたり、2006年以降発売の機種を調査の対象としていることは、その事実を隠そう!?としているようにも思えます。
2048bit未対応3G機種(ベリサイン)
https://www.verisign.co.jp/ssl/about/mobile_list.html
1024bit対応機種(セコムトラスト)
http://www.secomtrust.net/service/ninsyo/mobile_SSL.html
2048bit対応機種(セコムトラスト)
http://www.secomtrust.net/service/ninsyo/mobile_SSL_2.0.html
いろいろな情報を総合すると、2G以前の携帯端末はほぼ全滅ということになりますが、2013年以降はマイクロソフトがOSから1024bitのルート証明書を強制的に削除するという発表したこともあり、2、3年は混乱が続くものと思われます。
今3年以上の1024bit証明書をとってもPC対応は厳しく、かといって、2048bit証明書をとると携帯対応率が激減してしまうという、悩ましい選択を私たちは迫られています。
あなたはどう対応しますか?

SSL証明書 携帯電話のルート証明書

SSL証明書の関係で、「暗号化アルゴリズムの2010年問題」という話題を先日書きました。それでは、今(2010年7月現在)携帯電話にはどんなルート証明書が載っているのだろうか?
ドコモ、au、ソフトバンクの3キャリアに搭載されているルート証明書を日本で購入する場合の正規発行会社別に上げてみた。
エントラストジャパン http://japan.entrust.com/
Entrust.net Secure Server Certification Authority(Entrust Secure Server CA)
Entrust Root CA
サイバートラスト https://www.cybertrust.ne.jp/index.html
Baltimore CyberTrust Root
GTE CyberTrust Global Root
CyberTrust Global Root
セコムトラストシステムズ http://www.secomtrust.net/
Security Communication Root CA1
Security Communication RootCA2
コモドジャパン http://www.comodojapan.com/
AAA Certificate Service
AddTrust External CA Root
COMODO Certification Authority
日本ベリサイン https://www.verisign.co.jp/
VeriSign Class 3 Primary CA
VeriSign Class 3 Primary CA – G2
VeriSign Class 3 Primary CA – G3
VeriSign Class 3 Primary CA – G5
VeriSign Universal Root CA
(以下GeoTrustブランド)
Equifax Secure Certificate Authority
Equifax Secure eBusiness CA-1
GeoTrust Global CA
GeoTrust Universal CA
GMOグローバルサイン http://jp.globalsign.com/
GlobalSign Root CA
GlobalSign Root CA-R1
GlobalSign Root CA-R2(GlobalSign)
RSAセキュリティ http://japan.rsa.com/
RSA Secure Server Certification Authority
RSA Security 2048 V3
Valicert Class 3 Policy Validation Authority
ジェイサート http://www.jcert.co.jp/
Starfield Technologies, Inc.
The Go Daddy Group, Inc.
メディックス http://www.jp.thawte.com/
Thawte Premium Server CA
Thawte Server CA
全部で29個ありますが、auはLink to Link方式用に自社SSL証明書(KDDI SECURE NETWORK ROOT CA)を搭載しています。
これらはすべて使用されているわけではなく、将来のために搭載されているものもあります。つまり、暗号アルゴリズムが違うものだったりします。
ルート証明書というのは、SSL証明書毎に用意されているものかと思っていましたが、調べてみるとそうではありませんでした。
例えば、ベリサインでは、
「EV SSL証明書」でも「グローバル・サーバID」や「セキュア・サーバID」でも公開鍵長1024bit以下ではすべて「VeriSign Class 3 Primary CA – G2」を使用します。公開鍵長2048bitになると「VeriSign Class 3 Primary CA – G5」が使用されます。
ジオトラストでは、
公開鍵長1024bit以下では「Equifax Secure Certificate Authority」を使用し、2048bitでは「GeoTrust Global Root CA」を使用します。
コモドでは、
公開鍵長1024bit以下では「Equifax Secure Certificate Authority」を使用し、2048bitでは「COMODO Certification Authority」を使用します。1024bitまではジオトラストのルート証明書を借りて署名されていたため、携帯対応率が非常に高かったわけですが、2048bitになると自社ルート証明書に変更されるために対応率がかなり下がることになります。
今のところ調査していて1024bitと2048bitで同じルート証明書を使用するのは、セコムトラストの「Security Communication Root CA1」ぐらいですね。

Google Analytics 携帯版のデバイス(端末)毎のアクセスはどう見るか?

Google Analytics(グーグル アナリティクス) 携帯版を設定してみたものの「携帯端末」に表示されるのはキャリア名のみで、デバイス(端末)名が表示されないのはなぜ???って悩んでいました。
Google Analytics(グーグル アナリティクス) 携帯版
こういうデータです。(一部PC用OSが混ざってしまっていますが・・・実際の画面です)
手順を解説しているサイトは多数ありますが、どれも情報が古く、携帯版と言いながら機能変更でなくなったものと思っていました。
が!・・・
ようやく設定方法がわかりましたので、説明したいと思います。
Google Analytics(グーグル アナリティクス) 携帯版
まずは、左メニューの「カスタマイズ」メニューにある「カスタム レポート」をクリックします。
Google Analytics(グーグル アナリティクス) 携帯版
すると、このような画面(拡大可)が表示されますので、「カスタム レポートを新規作成」のリンクをクリックします。
Google Analytics(グーグル アナリティクス) 携帯版
レポートを自作できる画面(拡大可)になります。左メニューも何やら見慣れないものに変わります。よく見ると、メニューは昔のGoogle Analytics 携帯版メニューに近いようですね。
Google Analytics(グーグル アナリティクス) 携帯版
タイトルを編集できますので、「端末コード」とでも変更しましょう。
Google Analytics(グーグル アナリティクス) 携帯版
「ディメンション」の「システム」に「OSのバージョン」がありますので、それをドラッグして右のディメンションのところにドロップしましょう。
Google Analytics(グーグル アナリティクス) 携帯版
「指標」には「ユニークユーザー数」をドラッグ アンド ドロップしてタブ名を編集しておきます。
Google Analytics(グーグル アナリティクス) 携帯版
新規タブを追加すると、「ディメンション」はそのままですが、新しく「指標」を追加できます。「直帰率」を指定しておきます。
最後に下の「レポートを作成」ボタンを押すと・・・
Google Analytics(グーグル アナリティクス) 携帯版
デバイス(端末)名が表示されたレポートが追加されました。追加レポートは左メニューの「カスタム レポート」に追加されます。
しかし、WindowsOS名も混ざっていることから、標準メニューの「携帯端末」がデバイス名で表示されているほうがいいんですけどね。