nginxでのSSL証明書による認証+ Let's Encrypt

こんにちは、夕方または夜、それはすべてあなたが私の記事を読んだ日の時間に依存します。



法人顧客の数が増加したため、会計システムへのアクセスを外部ユーザーに許可することが決定されました。 注文の自己配置およびステータスの追跡用。 実装必要な機能とアクセスを備えたWebインターフェースが作成されました。 そこにはセキュリティの問題があり、標準のユーザーパスワードに加えて、セキュリティをさらに強化することを決定しました。OpenVPNを使用しましたが、OpenVPNを適用できないクライアント(セキュリティポリシー、不本意など)があり、 ssl証明書。







ソースデータ:



アカウンティングプログラムとWebインターフェイスを備えたサーバーはDMZにあります。

nginx、http(80)およびhttps(443)ポートのWEBサーバーはそこに転送されます。

Webサーバーでは、proxy_passはアカウンティングプログラムを使用してサーバー上で構成されます。アクセスはポート8080を介してのみ行われ、IP Webサーバーからのみ行われます。サーバーからのアクセスはありません(通常のセキュリティ)。

Let's Encryptからの証明書がアクセスのためにサイトにインストールされます。



ユーザー証明書の作成プロセスに進みます。



証明書の場合、ディレクトリ「/etc/ssl/crm.example.ru」を使用します



ディレクトリ構造を作成します。



# mkdir /etc/ssl/crm.example.ru # cd /etc/ssl/crm.example.ru # mkdir db # mkdir db/certs # mkdir db/newcerts # touch db/index.txt # echo "01" > db/serial # chmod 700 ./
      
      





証明書に署名するための構成ファイルを作成します。



/etc/ssl/crm.example.ru/ca.conf "

 [ ca ] default_ca = CA_CITENAME #       [ CA_CITENAME ] droot = /etc/ssl/crm.example.ru #    dir = $droot/db #    certs = $dir/certs #   new_certs_dir = $dir/newcerts #     (pem) database = $dir/index.txt #    serial = $dir/serial #    #    certificate = $droot/ca.crt #     private_key = $droot/ca.key default_days = 365 #     () default_crl_days = 7 #      default_md = md5 #   MD5 policy = policy_citename #   [ policy_citename ] countryName = optional #   stateOrProvinceName = optional # ....................... localityName = optional # ....................... organizationName = optional # ....................... organizationalUnitName = optional # ....................... commonName = supplied #   emailAddress = supplied # ..................... [ req_distinguished_name ] countryName =   (2- ) countryName_default = RU countryName_min = 2 countryName_max = 2 stateOrProvinceName =   ( ) stateOrProvinceName_default = Tyumen region localityName =   (, ) localityName_default = Tyumen 0.organizationName =   0.organizationName_default = EXAMPLE organizationalUnitName =    (, ) commonName =   commonName_max = 64 emailAddress = Email  emailAddress_max = 64
      
      





パスワードなしで自己署名証明書と新しいサーバーキーを作成します。



 # openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 \ -subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=crm.example.ru/emailAddress=crm@example.ru" \ -out ca.crt
      
      





または、すべてを手動で入力する場合。



 # openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 -out ca.crt
      
      





次のコマンドを使用して、秘密鍵と証明書データを表示できます。



 # openssl rsa -noout -text -in ca.key ( ) # openssl x509 -noout -text -in ca.crt ( )
      
      





クライアント秘密鍵と証明書要求(CSR)の作成:



 # openssl req -new -newkey rsa:2048 -nodes -keyout client01.key \ -subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=User example1/emailAddress=user@example1.ru" \ -out client01.csr
      
      





または、すべてを手動で入力する場合。



 #openssl req -new -newkey rsa:2048 -nodes -keyout client01.key -out client01.csr
      
      





ユーザーexample1の代わりに、クライアントのメールを指定できます。EXAMPLEでは、クライアントの会社を配置します。これは、証明書の追跡に役立ちます。



コマンドの結果として、client01.keyとclient01.csrの2つのファイルが表示されます。 次のコマンドを使用して、秘密鍵と証明書要求(CSR)のデータを表示できます。

 # openssl rsa -noout -text -in client01.key ( ) # openssl req -noout -text -in client01.csr ( )
      
      







信頼できる証明書(CA)を使用した証明書要求署名(CSR)。 要求に署名するときに、ca.configファイルで指定されたパラメーターが使用されます



 # openssl ca -config ca.config -in client01.csr -out client01.crt -batch
      
      





クライアントに送信するデータの準備。 以前の操作の結果として受信したファイルをクライアントに転送するには、通常、PKCS#12形式のファイルが使用されます。 クライアントがブラウザに証明書をインストールするために必要なすべての情報がパッケージ化され、このファイルにパスワードで保護されています。



 # openssl pkcs12 -export -in client01.crt -inkey client01.key \ -certfile ca.crt -out client01.p12 -passout pass:123ewqasdcxz
      
      





キーへのアクセス権を公開します。



 # chmod 600 /etc/ssl/crm.example.ru/client*.crt # chmod 600 /etc/ssl/crm.example.ru/client*.key
      
      





作成されたすべてのファイルを保存のためにdb / certsディレクトリに移動します。



 # mv ./client01.* db/certs/
      
      





nginxでは、インストールする必要があります:



  ssl_client_certificate /etc/ssl/crm.example.ru/ca.crt; ssl_verify_client on; ssl_verify_depth 1;
      
      





クライアントが証明書を使用して接続できるようにするには、client01.p12およびca.crtファイルを送信し、証明書をインストールするためのパスワードを提供する必要があります。 ca.crtは必要です。サーバー認証には使用しないため、Encryptを使用してみましょう。



証明書を発行するプロセスは自動化でき、スクリプトを書くだけでも難しくありません。 このようなクライアントは15人ほどいないため、すべてを手で運転しても問題ありませんでした。



私の作業例:



証明書選択ウィンドウ:







証明書自体:







暗号化してみましょう:







記事は資料の準備に役立ちました:



「SSL証明書を介したnginxのクライアントの承認」

「SSL証明書による認証」

「クライアントSSL証明書を使用した承認。 (ssl crypt mod_ssl apache) »

「偉大で強力なGoogle」



PS CheckはGoogle Chromeで実行されました。



All Articles