☰

独自の証明機関になった後、クライアント側の証明書を生成できない

tag-icon • tag-icon openssl squid
独自の証明機関になった後、クライアント側の証明書を生成できない

私私自身の認証局になった次のチュートリアルを実行した後:https://jamielinux.com/docs/openssl-certificate-authority/ より

ルート ペアを作成し、中間ペアを作成し、サーバー証明書に署名して、次のように squid にインストールしました。

http_port 3129 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/certs/gatesentry.csr.cert.pem key=/etc/squid3/key/gatesentry.key.pem

でsquid3.conf

Squid はこれで問題なく起動します。実際に動作するかどうかはまだわかりません。

プロキシ経由でインターネットにアクセスするブラウザにインストールするクライアント側証明書を生成しようとすると、次のエラーが発生します。

私はそれに基づいて生成します「証明書を作成する」と書かれた「サーバーとクライアントの証明書に署名する」セクション

認証用のクライアント証明書を作成する場合は、「usr_crt」拡張機能を使用する必要があると記載されているため、次のコマンドを実行します。

cd /root/ca
openssl ca -config intermediate/openssl.conf \
      -extensions usr_cert -days 375 -notext -md sha256 \
      -in intermediate/csr/gatesentry.csr.pem \
      -out intermediate/certs/client.cert.pem
Using configuration from intermediate/openssl.conf
Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4097 (0x1001)
        Validity
            Not Before: Jun 22 10:36:44 2016 GMT
            Not After : Jul  2 10:36:44 2017 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Pennsylvania
            localityName              = locality
            organizationName          = Parents
            organizationalUnitName    = Security
            commonName                = gatesentry.domain.lan
            emailAddress              = [email protected]
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Client, S/MIME
            Netscape Comment: 
                OpenSSL Generated Client Certificate
            X509v3 Subject Key Identifier: 
                XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
            X509v3 Authority Key Identifier: 
                keyid:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, E-mail Protection
Certificate is to be certified until Jul  2 10:36:44 2017 GMT (375 days)
Sign the certificate? [y/n]: y
failed to update database
TXT_DB error number 2

コマンドを root として実行しているときに (もちろん別のマシン上で)、TXT_DB エラー番号 2 のメッセージが表示される理由がわかりません。

チュートリアルによれば、このプロセス中に共通名を変更できるはずです。

答え1

TXT_DB error number 2DB_ERROR_INDEX_CLASH を意味します。

同じインデックスを持つ証明書を OpenSSL CA データベースに 2 回送信しようとしました。

この原因は通常、同じシリアル番号または同じ共通名を含む証明書をデータベースに送信したことにあります。後者の場合、ファイルunique_subject内のオプションを確認してください。intermediate/openssl.conf詳細については、を参照してください。man ca

クライアント証明書の共通名は、自分の名前など、何でもかまいません。

共通名はファイルで指定されますintermediate/openssl.conf。値の入力を求めるか、設定ファイルから値を読み取るかを設定できます。これはオプションによって制御されますprompt。詳細については、を参照してくださいman req。

答え2

チュートリアルによると、このプロセス中に共通名を変更できるはずです

そのチュートリアルでは、で新しいキーを生成し、openssl genrsaで新しいCSRopenssl req -newを作成し、でCSRから証明書を作成するopenssl caように指示されています。（ただし、多くの人が誤って「CSRに署名する」ことで証明書が作成されると言っています。CAはCSRに署名しません。CAは証明書に署名し、それが一部はCSR ですが、CSR とは異なります。/rant)

新しいCSRを生成する場合サブジェクト名を指定します。これには共通名が含まれますが、これに限定されません。共通名は、その上位のCA証明書とは異なる必要があります。すべき混乱を避けるために、他の EE 認定とは異なります。

openssl ca発行された証明書のサブジェクト名 (名前全体、共通名ごとではない) を実際に上書きできますが、これにより同じキーに対して異なる名前の証明書が作成され、不必要に混乱を招き、通常は安全性が低下します (その部分は気にしなくても、他の人は気にするため、簡単にはいきません)。

セクション usr-crt の拡張機能の読み込み中にエラーが発生しました
...値がありません...name=email_in_dn
これはアップストリームのデフォルト ファイルから来ている可能性があります...

直接ではありません。xxxopenssl ca -config xxxのみを構成ファイルとして使用します。ファイルがアップストリームから派生したものである場合、必要なセクション名はusr_cert明らかに発見したとおりですが、usr_cert はデフォルトであるため指定する必要はありません。email_in_dn に関するエラー メッセージはエラー スタックに残っているだけで、唯一の実際のエラーはusr-crt; でした。これを修正すれば不要になります-noemailDNが、いずれ必要になる場合があります。

これは subjectNameAlt と関係があるのでしょうか?

を意味していると仮定するとunique_subject、いいえ。subjectAltName( ではありませんsubjectNameAlt) 別名 SAN は、サブジェクトの別名を指定する一般的な拡張機能ですが、unique_subject基本Subjectフィールドのみを関連付け、SAN は関連付けません。

プロキシ経由でインターネットにアクセスするブラウザにインストールするクライアント側証明書

明確に言うと、このようなクライアント証明書は自分自身を認証する場合にのみ役立ちます代理人にクライアント/ブラウザの証明書を使用して、HTTPS MitM を介してインターネット上の何かに認証することはできません。また、自分で発行したクライアント証明書を使用して、インターネット上の他の誰かのシステムに認証することもできません。

関連情報