by
Anonymous Coward
on 2020年11月08日 21時08分
(#3920594)
そもそも、サーバというのは、リソースやディスクI/Oの急変だの急に吐かれたエラーログやら数秒に1回のサービス動作チェックへの応答がないときの対応やらその他で24時間体制で監視・対応するもの （それができないなら、できる業者にroot持たせた方が良い） 1年に1回の更新を手動でやったとして、サーバ1台管理する手間に加わる割合なんて微々たるものでしょ 手動の場合は、 ・11ヵ月に1回の更新タスクを職場の共有スケジューラー等にスケジュール ・普通にサーバ証明書をチェックして Not After まで1か月切ったら警告する管理スクリプトの作成 などの対応をして、1年に1回手動で更新すればいい
ユーザの積極的対応は期待できない (スコア:0)
ので、うちではLet's Encryptを使うのやめました。
予算だけ確保して、より具体的な日程が分かってから、
その日程に合わせてもうちょっとマシな証明書を買う予定。
Re: (スコア:0)
有効期限1年の証明書しか使えなくなったので、自動更新できないCAは使う気になれない。
管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
そもそも、サーバというのは、リソースやディスクI/Oの急変だの急に吐かれたエラーログやら数秒に1回のサービス動作チェックへの応答がないときの対応やらその他で24時間体制で監視・対応するもの
（それができないなら、できる業者にroot持たせた方が良い）
1年に1回の更新を手動でやったとして、サーバ1台管理する手間に加わる割合なんて微々たるものでしょ
手動の場合は、
・11ヵ月に1回の更新タスクを職場の共有スケジューラー等にスケジュール
・普通にサーバ証明書をチェックして Not After まで1か月切ったら警告する管理スクリプトの作成
などの対応をして、1年に1回手動で更新すればいい
Let's Encrypt で自動更新している人、本当に安全な方法で出来てる？
公式サイトは勿論、あちこちの情報サイト見ても、毎秒数百以上のアクセスがあるようなWebサーバで安全に更新できるようなスクリプトは全く見かけない
certbot certonly --webroot -w /home/www/www.example.com --noninteractive --post-hook "systemctl reload httpd.service" のような方法での解説、よく見かけるけど、
まずユーザーの端末の時計が数分狂っていたりタイムゾーンがずれていたりなんてこと（特に海外では）はよくあることなので Not Before 前の証明書扱いでエラーになるわけで
新たに取得した証明書は2～3日は寝かした方が良い
ユーザーの端末の時刻やタイムゾーン設定が絶対に合っている仮定しても、FirefoxだとOCSPが反映される数分間はエラー扱いになることが多いので、最低でも10分は待たないと駄目
そして、毎秒数百以上アクセスがあるようなWebサーバーだと再起動で少しでも負荷があがると直後の負荷が心配だから何かあったとき有人で対応できるときじゃないとリロードなんてすべきではない。
極端な話、スマートニュースやYahoo!ニューストップにサイトが掲載されたなどで急激なトラフィックが生じて負荷がぎりぎりのときにreload走ったら困るでしょ。
AWSのAuto Scalingだって急激なトラフィック急増には対応できないってのに
ってことで、サーバーのリロードは負荷状態が問題ないことを確かめたタイミング、かつ深夜などの影響が少ない時間帯、かつ有人で即座に人が対応できる状態でやるべき
負荷状況といっても、データベース負荷とか現在のコネクション数とか帯域とか色々見るところあるからなかなか自動化は難しい
Webサーバーのレスポンスが1～2秒遅延しただけで、いっきにDBサーバにまとまってSQLクエリが流れて、そこで過負荷でトラブルなんてこともよくある
Webサーバーのreloadっていうのは結構危険な作業だったりする
ってことで色々考えると、管理しているサーバの台数が数十やそこらだったら、変に自動化せずに手動でやったほうがトータルで良いと思われる
それでも、どうしても自動化したいならば、証明書の更新を自動化できるとこなんてCAなんて山のようにある
国内だと https://www.fujissl.jp/fujissl-go/ [fujissl.jp] とか
日本は古い体制のところが多いけど、海外含めればむしろ大手で自動化に対応できていないとこの方が少ないぐらい
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:2, 参考になる)
などの対応をして、1年に1回手動で更新すればいい
そうは言うけど、こういう話もあって、いつか有効期限1年の証明書も出なくなるかもしれない。
何度も短縮し過ぎ？！SSL証明書の有効期間がどんどん短くなる理由とは？ [sakura.ad.jp]
なお、自分の場合、今のところ1年に1回手動で更新している。会社指定のCAを使わないといけないので、自動化できるかどうかはそこ次第。
OCSPレスポンダ (スコア:1)
FirefoxだとOCSPが反映される数分間はエラー扱いになることが多いので、最低でも10分は待たないと駄目
ググったら、
https://help.sakura.ad.jp/360000143762/ [sakura.ad.jp]
JPRS社のSSL証明書は、OCSPレスポンダにSSL証明書の情報が登録されるまでに最大30分程度かかる場合があります。
このため、SSL証明書が発行された直後はOCSPによる失効情報の検証ができず、有効なSSL証明書として認識されないため、サイト閲覧時にエラーが出る可能性があります。
OCSPに対応しているブラウザをご利用の場合、SSL証明書発行直後は正常にサイトが閲覧できない可能性があります。
また、ブラウザのキャッシュにより1度アクセスすると最大6時間程度アクセスできない可能性があります。
だそうだが、Let's Encryptの情報は出てこなかった。
Let's Encryptだと最大何分？
Re:OCSPレスポンダ (スコア:1)
仮に CDN でキャッシュ機能があるとしてもサーバーに設定して証明書を使い始めるまでは OCSP リクエストがされることはないので、レスポンスがキャッシュされてしまうことはないと思います。
Let's Encrypt は、証明書を発行してから OCSP データベースに反映するまでのタイムラグもほぼゼロじゃないでしょうか。発行後すぐにレスポンスが返ってきそうです。
新規発行でも OCSPへの反映に 30 分もかかるのは遅くないですか？ CRL と中途半端に統合していてバッチ的に処理がなされているのでは？
Re: (スコア:0)
場末のショボいレンタル web サーバを手動更新してるけど、そんな大規模な人気サイトじゃないから、気にせず reload しちゃってるわｗ
というか、たぶん永久にそうならないけど、人気出たら CDN に肩代わりしてもらおうと思ってました。
負荷が高いサーバだと、考えることがたくさんあるのですね。
ところで、 CDN を使えば、オリジンサーバにはそこまで心配しないでもいいような気がしますが、別に考慮しなくちゃいけないこと出てきたりするのでしょうか。
Re: (スコア:0)
無料なところはともかく、有料のSSL証明書発行してるところは、
顧客のWebサイトの証明書を監視して、期限が近づくと警告するサービスをやればいのに
2か月前でメール警告、1か月前で再度メール警告、2週間前にメール＆電話＆手紙の両方で警告、みたいな
Re: (スコア:0)
Re: (スコア:0)
なんで監視する必要が？ 購入履歴からいつ頃警告メールを送るべきかは分かるはずなのだが。
他社の証明書を使ってるサイトに際し、そろそろ期限ですがウチに乗り換えませんか？って営業なら別だが。
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
エンジニアは自動化すること自体が仕事じゃないの？
単なる作業員なら学生アルバイトでいいわ。
Re: (スコア:0)
自分だけかもしれないけど、多少自動化で手間減らしたくらいでは「自分の存在自体が不要になる」にはならないと信じている。
それでも運良く（運悪く？）自分の首を絞めるほどなんでもかんでも自動化できてしまったら、異動するなり時機を見て転職するなりするよ。そのとき、職場に未練なんか残っているわけがないだろうから。
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
エクセルマクロ作ってルーティンを自動化したら、その部署の人員半分にされたとかはよく聞く話だけど、
仮にもエンジニアであるならば自動化もできない人の方が首切られて終わるかも。
Re: (スコア:0)
むかしの大企業や金融機関には、そろばんができる多数の経理担当社員(ほとんど女)がいた
コンピュータ化によりそれらの仕事がなくなった
それでも昭和時代はかわりの職があったが、平成時代になってからかわりの職がなくなった
平成になってから、中小企業でも経理担当社員の数は大幅に減った
Re: (スコア:0)
だからどっちにしろ「自分の存在自体が不要になる」とか考えて自動化を考えない運用エンジニアは早晩クビになる。
お前がやらなければ誰かがやる。その「誰か」は功労者として評価されるが、何もしなかったお前はただクビになるだけ。
だったら率先してやった方が幸せになれる。
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
それが computer なわけですが
Re: (スコア:0)
おかしいなぁ、日々構成と内容を理解してWebサーバーを適切に運用できるぐらいだったら食いはぐれないはずなんだがなぁ。
インフラ運用屋の需要はどこまで行ってもなくならないよ、むしろ最後まで残る。
サーバー構築や設計、ネットワーク領域までできれば社内情シスとしての道も開けてやっぱり最後まで残れるコース。
機械がトラブルが起きた時の自動化は限界があるから、それをどうにかするのは結局人間の仕事よ。
切られると思っているのは、自分が切られるだけの仕事しか任されていないと認識しているからじゃない?
その危機感を持っているのであれば、安心できるまで学びましょ?教材コストがここまで激安な業界は少ないんだから。