This time I have tested the OnTime group calendar.
I was annoyed by the iNotes login screen that was not supposed to appear...or rather, my own misconfiguration that caused confusion for the support staff.
みなさま、こんにちは。
さてまずは告知から・・・
アジェンダ(予定)
・HCLタイム
・NOTES er が Basic Notes にムチ打って、無理させた件
・大阪研サーバーのメールセキュリティ対策
・ほんとにあった怖いNotesアプリの設計
・欲求の4タイプでわかるあなたと他人
・HCL Nomadアプリ開発(仮)
大阪研のカラーが満喫できる半日になるはず。
現地に関わらず、リモート参加も大歓迎です。
コンソーシアム会員にかかわらず、ゲスト参加も大歓迎です。ぜひタイトルリンクよりお申込みください。
I am pleased to report that automatic updates of Let'sEncrypt are now working with Domino V12.0.1 and Amazon Route53.
In conclusion, I felt that this feature should definitely be used if your environment allows it!
みなさま、こんにちは。
さて先日、第一回大阪研究会を開催させて頂きました。
簡単にブログ記事にて公開致しておりますので、ぜひご一読ください。
こちらにも書いていますが、今年の大阪研は研究会活動以外にも活躍の場を広げて参ります。
ぜひご期待ください。!
さて今回は弊社で運用してますDominoサーバー2台(アプリケーション+メール、Traveler)の証明書をLet's Encrypt + AWS Route53への切り替えで、自動更新に成功しましたので、報告させて頂きます。
あらかじめお断りですが、本作業は私が実施したのではなく、株式会社エフ。
そう、エフといえば御代アンバサダー・・・にお願いして、実装して頂きましたので、設定手順等については説明致しませんので、ご了承ください。
まずは背景です。
弊社では従来、両サーバーは自己証明書を利用していました。
つまりブラウザからアクセスする場合、毎回以下のような画面が表示され、無理やり開く必要があったのです。
邪魔くさいですよね～
社内で配布するマニュアルもこの画面を経由してログオンするマニュアルになってました(汗
ただ証明機関を利用した証明書となると、結構費用が発生してしまいます。・・・・Let's Encryptを除いては!!
そういえば、以前に中野アンバサダーの以下記事を読んで興味を持っていたことを思い出しました。
Let's Encrypt で取得したマルチドメインでワイルドカードなTLS 証明書をエクスポートしてみた
V12.0.1ではCertMgrが強化されているのでしたら、ぜひ使ってみたい。
弊社の環境はイントラ内の閉じた空間にDominoが、DMZにTravelerが存在しています。
CertMgrではHTTP-01チャレンジとDNS-01チャレンジが利用できるのですが、HTTP-01チャレンジは対象サーバーがLet's Encryptと80番ポートでの通信が必要なため、弊社ではDominoサーバーがNG。
ということでDNS-01チャレンジを選択することとなりました。
DNS-01チャレンジの場合、対応できるDNSサービスを利用する必要があるのですが、たまたま・・・ほんとうにたまたま、弊社では近々にAWS Route53へ移行の準備を進めていたのです。
先の中野アンバサダーのブログでも、Route53を使って成功したと書かれており、トライしてみることとしたのです。
エフ様に依頼して数日。
この間、エフ様でも弊社と同じ環境を準備頂け、そちらでテストの上、概要と手順書を作成して頂けました。
それらを利用し、2月28日 13時から実環境の作業に入りました。
弊社の環境でひとつ引っかかったのが組織でした。
弊社ではDominoとTravelerを別の組織にしてしまっていたのです。
こうなると、Dominoサーバーで取得したワイルドカード証明書をTravelerで利用できないことが判明しました。
従って、両方のサーバーに更新するプログラムと設定を追加することとなりました。
まずはDomino。
ちょっとしたトラブルはありましたが、スムーズに完了することができました。
続いてTraveler。
こちらは先のDominoの内容をコピーしつつだったので、問題ないかと思いきや、エラー!!
しばらくふたりで頭を抱え、いろいろと調べてみました。
御代様が細かなログを見ていて気付きました。
サーバーとRoute53のやり取りで、一時的にDNSに「_acme-challenge.ドメイン」というTXTレコードを追加し、それをキーに認証が進むことで証明書が発行されるのですが、Travelerサーバーに関して、既にこのキーがなぜか存在していたのです!
なぜこんなキーがあるのかは不明なのですが、恐らく使っていないだろうと判断して、既存キーをリネームして再度実行したところ、無事証明書を取得することができました。
Verseを開くと、もちろん証明書エラーの画面は表示されず、鍵がかかった表示となりました。
鍵マークをクリックすると、「この接続は保護されています」となり、
さらに▶をクリックすると、「証明書は有効です」となっています。
最後に証明書です。
以下が自己証明書になります。
消してしまってますが、文字通り「発行元」と「発行者」が同一であり、アイコンも×が押されています。
以下が今回取得したものです。
発行先は先と同じなのですが、発行元が「R3」となっています。
もちろんアイコンには×はありません。
ちなみにLet's Encryptの証明書は有効期間は3カ月なのですが、両サーバーの設定を証明書期限の30日前で設定しています。
っとここまでで公開してもよかったのですが、せっかくなので自動更新を確認してから本記事を公開させて頂くこととしました。
少し社内の確認作業があり、Travelerサーバーは一度手作業で更新してしまったので、アプリケーションサーバーのみの結果になります。
まず早速ですが、証明書を確認します。
期限が2022/04/30からのものに変わっていました。
つぎにCertManagerの内容を確認します。
最終更新が 2022/04/30(土) 13:39:27 になっており、証明書の更新日、有効期限も適切に処理が完了されていました。
さらにトレースログです。
一部内容ですか、以下となります。
DNSのTXTレコードを書き換えていることがわかりますね。
ちなみに前回の証明書はアーカイブされています。
