おれおれ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構築するぞ!

WAONでワォン!

吉野家WAON
5月に申し込んでいた吉野家WAONが先々週ようやく届いた。
そして今日の昼にWAONデビューしてきました!
「ワォン」
あれ!「ワォーーン」じゃないの?
大人の犬ではなく、子犬なのか?
というより吉野屋でチャージできないのが不便だな。

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名も混ざっていることから、標準メニューの「携帯端末」がデバイス名で表示されているほうがいいんですけどね。

SDガンダム ガシャポンウォーズ

「Wii スポーツ リゾート」以来一年ぶりにWiiのゲームを購入した。ということで、Wiiの電源が入るのも一年ぶりとなる。
SDガンダム ガシャポンウォーズ
SDガンダム ガシャポンウォーズ
もう15年も前になるが、学生時代にゲームをやりつくした感があって、最近の綺麗なだけの長いゲームや小難しいだけのゲームはやる気がしなくなっている。
SDガンダム ガシャポンウォーズ
まずは「シナリオモード」からはじめてみる。ゲームの操作方法を教えてくれながらシナリオが進むモードだ。
SDガンダム ガシャポンウォーズ
戦闘はアクションゲームになっている。単純だが面白い。ゲームもさくさくと進むので久しぶりにハマってみようか。
今日、Wiiを最初に電源を入れたとき画面が映らなかった。原因は有線LAN用のアダプタ・・・。どうも調子が悪いらしく通信したり止まったり、ちょうど画面の切り替え時に通信が止まるとWiiが固まる。どうしようもないというより、システムアップデートでアダプタが不安定になっていないか?

箔打ち実演 見納め、あぁ残念

「鏡花と能楽」 泉鏡花記念館
北陸らしい?梅雨空の下、泉鏡花記念館へ行ってきました。
「鏡花と能楽」 泉鏡花記念館
同館では、鏡花の「能楽もの」の代表作である「歌行燈」の成立100年を記念して、金沢能楽美術館と共催による展示を行っています。能楽が作品に取り入れられているものがたくさんあるようですね。
「総集編」 安江金箔工芸館
続いて、今月末で長期休館となる安江金箔工芸館へ行ってきました。
「総集編」 安江金箔工芸館
昭和49年の開館からの総集編として、名品の数々が展示されていました。
箔打ち実演
そして、最後の箔打ち実演を見てきました。今日は報道もたくさん来ていましたよ。
金箔を正方形に切る作業しか見たことがなかったので、箔打ち作業は始めてみます。ちなみに、箔を切るのは「竹」でつくられた道具です。「箔」が竹冠なのは意味があるんですよ。
箔打ち実演
大きな音を立てながら箔を引き伸ばしていき、温度が上がったところを冷ますついでに、広がり具合や厚さにムラがないかどうかをチャックするそうです。この作業は1グラムを1ミクロンになるまで3、4日続けられるそうで、これが非常に重労働です。
金箔工芸館は、7月から長期休館に入り、秋にひがし茶屋街の近く、東山にリニューアルオープンしますが、近辺に金箔体験が多いことや、箔打ちの音が近所に騒音になるということから、実演コーナーは廃止となり、展示のみとなるそうです。非常に残念なことです。

卯辰山 菖蒲園は今が見頃!

金沢市の北東に位置する卯辰山の菖蒲園は今が見頃です!
小雨が降り始めた中でも、見頃の菖蒲を見ようとたくさんの人が来ていました。
卯辰山 菖蒲園
手前の池だけでなく、奥の斜面にも多くの菖蒲が植えられています。
卯辰山 菖蒲園
菖蒲と言ってもいろいろな色、形がありますね。
卯辰山 菖蒲園
卯辰山 菖蒲園
卯辰山 菖蒲園
卯辰山 菖蒲園
卯辰山 菖蒲園