SECLEVEL=0 は症状を治すが、証明書を治すのではない

OpenVPN の接続が失敗し、誰かが SECLEVEL=0 を追加する一行の修正を見つけると、トンネルは上がります。変わったのは証明書でも暗号スイートでもなく、ライブラリ全体の受け入れしきい値が動いたのであり、その後プロセスが行うすべては新しい境界を引き継ぎます。同じ一行が環境内のあらゆるプロファイルにコピーされる前に、これを理解しておく価値があります。

どのライブラリとどのポリシーが有効なのかを突き止める

SECLEVEL は OpenSSL の概念なので、最初の問いはあなたのビルドがそもそも OpenSSL を使っているかどうかです。OpenVPN は複数の暗号ライブラリにリンクでき、その一つに当てはまる設定は他には無意味です。バイナリに何でビルドされたかを尋ね、次にライブラリにどのバージョンと設定を読み込んだかを尋ねてください:

openvpn --version | head -3
openssl version -a

バージョンの出力は、ディストリビューションが既定値をパッチしているため注意深く読んでください。最小レベルを上流の既定より引き上げるシステム設定を同梱するものがあり、そのため同じ OpenVPN パッケージを持つ二台のマシンで同じプロファイルが違う振る舞いをします。有効なポリシーは実行中のプロセスが読み込んだものであって、上流のマニュアルにあるものではありません。

次に、人が混同する二つの層を分けてください。OpenVPN には独自の TLS 制御があり、証明書プロファイルの設定や明示的な暗号リストが含まれ、それらはライブラリが強制するものの上に位置します。ライブラリのレベルを下げても、OpenVPN の設定がどの暗号を列挙するかは変わりませんし、OpenVPN のリストを狭めても、ライブラリのしきい値は上がりません。どちらの層があなたを拒否したのかを知ることが、修正を推測のままにしないための鍵です。

拒否されうる三つのものを切り分ける

最初の候補は ID 素材です：鍵が小さすぎる証明書、あるいは署名アルゴリズムがポリシーにもう受け入れられない証明書です。二つ目は鍵交換のパラメータで、ポリシーが弱すぎると見なすグループなどです。三つ目はポリシーが除外する暗号スイートです。三つともハンドシェイクの失敗を起こしうるので、エラーの文言と交渉の段階だけがそれらを区別します。

その三つのどれもデータチャネルの暗号ではありません。OpenVPN はトンネルの暗号化を TLS ハンドシェイクとは別に交渉するので、セキュリティレベルの変更後に成功した接続は、どの暗号がペイロードを守っているかについて何も語りません。本当に尋ねているのがデータの機密性についてなら、あなたはまったく間違ったつまみを見ています。

レベルを下げると、三つの入力すべての受け入れが同時に広がります。ここが見落とされる部分です：古い証明書を通す修正は、弱いグループと、おそらく許可するつもりのなかったスイートも通します。一つのエラーが変更のきっかけで、変更はエラーより広いのです。この非対称性こそ、限定的な例外が環境全体の既定値より優れている理由です。

しきい値ではなく入力を変える

設定に触れる前に、それを報告した段階と名指ししたオブジェクトも含めて、正確なエラーを保存してください。証明書の問題は、同じファイルを再インストールするのではなく、現在のポリシーが受け入れるものに証明書を置き換えること、つまり認証局からの再発行で解決します。

拒否された入力があなたの管理しないピアのものであるなら、話し合う相手はそのピアの所有者で、内容は対応済みの代替素材についてです。誰も保守しないシステムに合わせて自分のしきい値を下げることは、コストを彼らから、その後につながる全員へ移すことになります。

サーバーがポリシーを強制している場所では、ライブラリを責める前に、OpenVPN レベルの設定が実際の原因ではないか確認してください。配備済みの証明書が満たせない厳しいクラスを要求する証明書プロファイルは、セキュリティレベルが何であれ失敗しますし、そのプロファイルを外すほうがライブラリの検査を無効にするより狭い変更です。

下げざるを得ないなら、範囲を絞って記録する

承認された互換性の例外が正解になることもあり、特に廃止予定日のある旧式のピアではそうです。ホスト全体ではなく必要とするサービスに限定してください：サービスごとの設定ファイルや専用の OpenSSL 設定は、グローバルプロファイルでのエクスポートより影響範囲が小さいのです。

例外とともに、正確な設定、承認した所有者、影響を受けるクライアント、そして削除する条件という四つのことを書き留めます。廃止条件のない例外は、一時的な正当化を添えた恒久的な弱体化です。

ロールバックは、すでに試した一つの手順であるべきです。以前の設定を保持し、変更を適用し、サービスが起動することを確認し、次の接続が想定と違う挙動をしたときにどのファイルを戻すかを正確に把握しておきます。

その後で ID と保護を検証する

接続が成功したのは、改訂された条件がそれを許したというだけのことです。ホスト名とピアの検証が今も各々の役割を果たしていること、使われている証明書が配備するつもりだったものであること、交渉されたデータチャネルが想定しているポリシーと一致することを確認してください。

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

OpenSSL のセキュリティレベルのリファレンスは、フレームワークが鍵、署名、グループ、スイートに一斉に制限を課し、レベル零がコールバックの検査するすべてを許可すると明言しています。それがあなたの変えた範囲であり、修正は狭かったのかと問われたときに引用すべき文です。

監査に耐える引き継ぎは、どのポリシーがどの入力を拒否したのか、何を変えたのか、その結果として何がなお受け入れられるのかを述べます。「SECLEVEL=0 で動く」は一つの接続についての観察であり、配備のセキュリティ評価ではありません。