DigiLoog

自宅サーバの仮想イメージを格納しているiSCSI用のNASがあるのだが、
OSを半年以上アップデートしていない事に気づいたので、
近い内にOSアップグレードを計画中。

主要サーバは別の仮想サーバ基盤で動いているので完全停止はしないが、
手元に近い検証環境を全て停止させる必要があるので大き目な作業になる。
しかも以前アップグレードした時にSNMPが取得出来なくなり、
ダウングレードした事もあるので切り戻し手段も準備せねば。

“ns-lab BB”の主要サーバはLet’s EncryptのSSL証明書を利用しているが、
一部サービスでは認証局からSSL証明書を購入して使っている。

購入している方では、セコムトラストのSSL証明書を利用していたが、
数年使い続けていたのと他社も使ってみたかったのでJPRSに乗り換える事とした。
この乗り換えに罠が潜んでおり、見事にトラップカードが発動したので備忘録を残す。

起きた事は明確で、権威DNSにJPRSのCAAレコード追加を忘れており、
ルートCAのSSL証明書発行プロセスで順当に拒否された (´・ω・`)

CAAレコードは、該当ドメインで発行を許可する認証局を指定する事で、
意図しないSSL証明書の発行を抑制する仕組み。

正直な所、自宅サーバレベルならCAAレコードは不要なのだが、
一部のHTTPS判定サイトの評価基準にCAAレコード登録があったので数年前に登録した。

今回はCAAレコードを更新していなかったのが問題なので、
セコムトラストのCAAレコードを削除して、新たにJPRSのCAAレコードを追加した。
この状態で改めてSSL証明書の発行をJPRSに依頼した所、無事に審査が通り発行出来た。

CAAレコードは殆ど弄らない設定だからこそ忘れていた。
まだ馴染みが無いCAAレコードだが、
YahooやGoogleなど大所は設定されているので徐々に普及していくと思われる。
自鯖で必要なシーンはほぼ無いが、自鯖だからこそ出来る設定でもあるので、
当面はこのままレコードを管理しようと思う。

« 続きを隠す

普段利用しているのは、DigiLoogも稼働しているwww.ns-lab.orgのFQDNだが、
検証用FQDNや全く別の内部用ドメインも所有もしている。

内部用は独自CA認証局を立てて証明書を管理しているのだが、
一部のFQDNはインターネット上の別サーバと連携しており、
システムを動かす為にパブリックなSSLサーバ証明書を導入している。
普通ならLet’s Encryptでも大丈夫なのだが、
システムの仕組みが問題で買うしかないので買う事にしている。

このSSLサーバ証明書にはFuji/SSLを用いているのだが、
更新時期になった事もあり、今回を機に他の証明書にも手を出すか模索中。