1. 証明書と公開キー・インフラストラクチャの管理
  2. OpenSSLを使用したTLS/SSLの設定

2 OpenSSLを使用したTLS/SSLの設定

この章では、Oracle Linuxで使用可能なOpenSSLツールと、それらを使用して証明書署名リクエスト(CSR)、自己署名証明書および独自のCA証明書を作成する方法について説明します。また、この章では、OpenSSLツールを使用して、プロトコル用に構成された証明書を検証およびテストし、サービスが正しく構成されていることを確認する方法についても説明します。

opensslコマンドの機能

opensslパッケージに含まれるopensslコマンドを使用すると、OpenSSLライブラリから次のような様々な暗号化機能を実行できます。

  • 秘密キーと公開キーのペアを作成および管理します。

  • 公開キー暗号化操作を実行します。

  • 自己署名証明書を作成します。

  • 証明書署名リクエスト(CSR)を作成します。

  • 証明書失効リスト(CRL)を作成します。

  • 証明書ファイルを様々な形式間で変換します。

  • メッセージ・ダイジェストを計算します。

  • ファイルを暗号化および復号化します。

  • クライアント側とサーバー側のTLS/SSLをHTTPサーバーとSMTPサーバーでテストします。

  • S/MIME電子メールを検証、暗号化および署名します。

  • 素数を生成およびテストし、擬似ランダム・データを生成します。

キー・ペアの作成

公開キー暗号化を使用する最初のステップとして、公開キーと秘密キーのペアを作成します。次に、秘密キーを使用して、関連付けられた公開キーを含む証明書署名リクエスト(CSR)を作成できます。CSRを使用して、CAから署名付き証明書を取得できます。通常、キー・ペアとCSRまたは自己署名証明書を作成するステップは、OpenSSLを使用してこれらのファイルを生成するときには、単一ステップの操作として実行されます。

後に示す手順と例では、プロセスを適切に記述し、要素の理解に役立つ説明を追加できるように、キー・ペアの作成は分割できない操作として扱っています。通常、このステップは、効率を上げるために他のコマンドに組み込まれています。

キー・ペアを作成するときに考慮する必要がある主な要素は次のとおりです。

  • アルゴリズム

    OpenSSLはRSAおよびECDSAキー・アルゴリズムの使用を提供しており、RSAキーが最も広く使用されています。DSAキーは作成できますが、必要でないかぎり使用しないでください。ECDSAは、RSAとDSAの両方と比べてキー・サイズをはるかに小さくし、対応するセキュリティを提供する最新のバリアントです。ECDSAは、パフォーマンスの観点でよい選択の場合があります。ただし、一部の環境ではECDSAキーが認識されない可能性があることに注意してください。

  • キー・サイズ

    キー・サイズは、アルゴリズムのキーの複雑さをチェックするもので、ビット単位で指定されます。キーのサイズを大きくすると、より複雑で解読が難しくなるため、より安全です。各ビットの復号化が完了するためにはより多くのメモリーと処理が必要になるため、キーのサイズが大きくなると、パフォーマンスが低下するという影響もあります。したがって、キー・サイズはセキュリティとパフォーマンスのバランスを考慮して選択します。キー・サイズは複雑で、使用されているアルゴリズムおよび暗号に関連しています。一般的に、RSAキーを作成する場合、キー・サイズは2048ビットにしますが、ECDSAキーは256ビットのキー・サイズを使用して同様のセキュリティを提供します。

  • パスフレーズ

    暗号化され、暗号によって保護されるキーを作成する場合は、キーを使用できるかどうかを検証するために使用できるパスフレーズの入力を求められます。パスフレーズを使用してキーを暗号化することはオプションですが、お薦めします。TLSがシステム・サービスで有効になっている場合、ユーザーの介入なしにサービスを自動的に再起動できないため、キーでパスフレーズを使用すると問題が発生する可能性があります。多くの場合、サービスに対して証明書が発行される場合には、便宜上、パスフレーズなしで証明書が作成されます。秘密キーがパスフレーズなしで作成された場合、秘密キー・ファイルへのアクセス権を持つ誰もが、サービスをエミュレートして中間者タイプのスヌーピングを実行できることに注意してください。キーがパスフレーズで保護されている場合は、秘密キーの内容を暗号化するために使用する暗号アルゴリズムを選択できます。この目的では、多くの暗号を使用できます。暗号の完全なリストを取得するには、openssl list-cipher-commandsコマンドを使用します。AES暗号はこの目的で一般に使用され、通常は128または256 (aes128またはaes256)のキー・サイズで指定されます。

RSAキーを生成するには、openssl genrsaコマンドを使用します。次に例を示します。 

sudo openssl genrsa -out private.key 2048

Generating RSA private key, 2048 bit long modulus
...................................................
....................................................
...................................................+++
................................+++
e is 65537 (0x10001)

このコマンドは、private.keyという暗号化されていないキーをローカル・ディレクトリに生成します。キーの内容は、次の例のようになります。 

cat private.key

-----BEGIN RSA PRIVATE KEY-----
...[certificate text]
-----END RSA PRIVATE KEY-----

ファイルはprivate.keyと呼ばれ、ファイルにはこれが秘密キーのみであることを示すテキストが含まれていますが、公開キーもこのファイル内に埋め込まれていることに注意してください。したがって、単一のファイルが完全なキー・ペアを表します。このため、公開キーのコピーの取得は、秘密キーと同じファイルに公開キーが格納されるため簡単です。

パスフレーズを使用して暗号化キーを作成するには、同じコマンドを実行しますが、キーの暗号化に使用する暗号を指定します。次に例を示します。 

sudo openssl genrsa -aes256 -out private.key 2048

Generating RSA private key, 2048 bit long modulus
............+++
.............................................................+++
e is 65537 (0x10001)
Enter pass phrase for private.key:
Verifying - Enter pass phrase for private.key:

前述の例では、AES暗号が256ビット・キーで使用されています。このコマンドでは、パスフレーズを入力して検証するよう求められます。次の例に示すように、キー・ファイルの内容は、キーが暗号化されていることを示しています。 

cat private.key

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,2417E359B45960CD107A390748945752

key-content
-----END RSA PRIVATE KEY-----

暗号化されたキー・ファイルを作成した後、暗号化されていないファイル、またはパスフレーズを必要としないファイルを使用する場合は、次のコマンドを実行してファイルを復号化できます。 

sudo openssl rsa -in private.key -out unencrypted.key

Enter pass phrase for private.key:
writing RSA key

private.keyに格納されている暗号化されたキーのパスフレーズの入力を求められ、同じキーの暗号化されていないバージョンがファイルunencrypted.keyに書き込まれます。

すべてのOpenSSLキーは、Privacy Enhanced Mail (PEM)形式で生成されます。これは、キーの内容をbase64でエンコードされた文字列としてカプセル化するプレーン・テキスト形式です。証明書は、いくつかの異なる形式規則を使用してエンコードできます。証明書の形式を変更する方法の詳細は、キーまたは証明書形式の変更を参照してください。

秘密キーの内容は、次のように表示できます。 

sudo openssl rsa -text -in private.key

特に、秘密キーには対応する公開キーも含まれています。この公開キー・コンポーネントは、CSRの送信時または自己署名証明書の作成時に使用されます。公開キー・コンポーネントは、次のコマンドを使用して表示できます。 

sudo openssl rsa -pubout -in private.key

OpenSSLを使用した証明書署名リクエストの作成

秘密キーを使用して、証明書署名リクエスト(CSR)を作成できます。公開キーと秘密キーを使用して通信を暗号化できます。ただし、クライアントは、暗号化された通信で使用するために提示された公開証明書を、期待される信頼できるソースからのものとして検証する必要があります。公開キーを検証する方法がない場合、クライアントは、暗号化を無効にする中間者方式の攻撃に簡単に侵害される可能性があります。

この問題を解決するために、公開キー・インフラストラクチャには通常、認証局(CA)と呼ばれるサード・パーティが関与し、特定の公開キーに対して真正として証明書に署名できます。クライアントにCA証明書のコピーがある場合、クライアントは証明書の署名に基づいてドメインの証明書を検証できます。ほとんどのシステムには、デフォルトでいくつかの信頼できるCA証明書がインストールされています。システムによって信頼されているCA証明書を確認するには、次のコマンドを使用します。 

sudo openssl version -d

デフォルトでは、このディレクトリは/etc/pki/tlsで、/etc/pki/tls/certsサブディレクトリにすべての信頼できる証明書が含まれています。

CAから署名付き証明書を取得するには、関連付けられた秘密キー内の公開キー・コンポーネントを使用してCSRを生成する必要があります。CSRは次にCAに提示され、CAはリクエスト内の情報を検証し、この情報を使用して有効な署名付き公開証明書を生成します。CSRは、証明書が使用されるホストのドメイン名に関連付けられています。CAはこの情報を使用して、指定した有効期限を持つ証明書を作成します。

次の例は、秘密キーからCSRを対話形式で作成するためのコマンド構文を示しています。 

sudo openssl req -new -key private.key -out domain.example.com.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:London
Organization Name (eg, company) [Default Company Ltd]:Example Ltd
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:domain.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

デフォルト値は/etc/pki/tls/openssl.cnfファイルで構成できます。Common Nameは、CSRで最も重要な値です。この値は、証明書リクエストを、証明書が使用されるホストのホスト名とドメイン名に関連付けます。別のドメインの証明書が発行されたホストにクライアントが接続した場合、その証明書は無効になることに注意してください。

CSRと秘密キーを同時に生成できます。次のコマンドを使用すると、コマンドラインでCSR内の様々なフィールドの値を指定できます。 

sudo openssl req -new -nodes '/CN=domain.example.com/O=Example Ltd/C=GB/L=London' \
  -newkey rsa:1024 -keyout private.key -out domain.example.com.csr

CSRに含まれる情報は、次のように表示できます。 

sudo openssl req -in domain.example.com.csr -noout -text

CSRを作成したら、それをCAに送信できます。CAはCSRを使用して署名付き証明書を生成し、証明書の検証に使用できる証明書チェーンを使用して証明書を返します。

OpenSSLを使用した証明書の署名

クライアント・システムを制御できない環境では、常に認識された独立したCAを使用して証明書に署名する必要があります。オペレーティング・システムおよびソフトウェア・ベンダーは、独立したCAと交渉して、配布するソフトウェアとともにCA検証証明書を含めます。主要なCAプロバイダから検証証明書を取得することは、ほとんどのユーザーが各自の信頼できるCA証明書リストを管理する必要がないことを意味します。HTTPS経由でWebサイトにアクセスするブラウザは、CA署名を自身のストアにあるCA証明書と照合することで、サイトの公開証明書を検証できます。

クライアント・システムを制御できる場合は、クライアントに自己署名証明書を直接提供するか、プライベートCA証明書を設定し、組織内で使用されるすべての証明書に署名してから、クライアントにCA証明書を配布できます。2番目のアプローチを使用した場合、組織内で署名されたすべての証明書が検証され、組織内の証明書のセキュリティをより厳密に制御できるため、インフラストラクチャ・コストを削減できます。

テストおよび開発用の自己署名証明書の作成

自己署名証明書は、多くの場合、開発およびテストの目的で作成されます。これらの証明書は信頼できるCAによって検証されないため、これらの証明書の信頼は手動で構成する必要があります。秘密キーが危殆化されている場合は取り消すことはできませんが、トラスト許可リストから手動で削除する必要があります。これらの証明書は、本番環境では使用しないでください。CA署名証明書は、常に自己署名証明書よりも優先されます。ただし、自己署名証明書を使用すると、独自のCAを管理したりテスト・プラットフォームごとにCA署名証明書を取得する手間をかけずに、コストを抑え、テストと開発に役立てることができます。

opensslコマンドを使用すると、すぐに使用できる自己署名証明書を生成できます。このコマンドは、秘密キーのCSRを作成し、CSRから直接X.509証明書を生成し、それ自体で証明書に署名します。

このため、コマンドは秘密キーとCSRを作成するために実行するコマンドに似ていますが、有効期間も指定する必要がある点が異なります。よい方法として、自己署名証明書は、テストの目的で必要な期間にのみ生成します。これにより、秘密キーの安全性が損なわれた場合、有効期間が制限され、古い証明書の期限が切れたときに新しい証明書を生成できます。

たとえば、次のコマンドを使用して、30日間有効な自己署名X.509証明書を作成します。

sudo openssl req -new -x509 -days 30 -nodes -newkey rsa:2048 -keyout private.key \ 
  -out public.cert -subj '/C=US/ST=Ca/L=Sunnydale/CN=www.example.com'

生成されたprivate.keyファイルには秘密キーが含まれ、public.certファイルには自己署名証明書が含まれます。通常、どの証明書とキーがどのホストとドメイン名に適用されるかを追跡できるように、これらのファイルに共通名と同じ値を使用して名前を付けます。

-newkey値は、カスタム・アルゴリズムおよびキー・サイズの要件にあわせて設定できることに注意してください。この例では、アルゴリズムはRSAに設定され、キー・サイズは2048ビットに設定されています。

自己署名証明書ファイルは任意のクライアント・システムの信頼できる証明書ストアにコピーでき、クライアント・システムは、証明書を提供するホストに接続するたびに、証明書が一致することを検証します。

keytoolコマンドを使用して自己署名証明書を生成することもできますが、このコマンドの主な目的はJavaアプリケーションで使用するJSSE (Java Secure Socket Extension)デジタル証明書をインストールおよび管理することです。詳細は、Javaを参照してください。

プライベート認証局の作成

プライベート認証局(CA)を作成することによって、組織内のすべての証明書のCSRを処理できます。また、独自の証明書失効リスト(CRL)を管理することもでき、これを使用して、クライアント・システムは、証明書がまだ有効であるか、失効しているかを検出できます。

この方法は、失効を制御できるため、自己署名証明書を使用するよりも優れています。ただし、CA証明書は、組織内の公開証明書を検証する必要があるすべてのクライアント・システムに配布する必要があります。

CAルートの作成

CAルートはCAの基本証明書であり、通常、サーバーまたはクライアント証明書の署名には使用されません。CAルートは、通常、1つ以上の中間証明書に署名して、他の証明書に署名する権限を付与するために使用されます。このモデルは、CA中間秘密キーの安全性が損なわれた場合、CA中間を証明書失効リストに追加でき、中間によって署名されたすべての証明書が自動的に無効化されることを意味します。

このモデルは、公開キー・インフラストラクチャ全体の整合性の保護に役立ちます。CAルートは階層内のすべての証明書の検証に使用される信頼チェーンの作成に使用されるため、CAルートを使用しない場合、公開キー・インフラストラクチャはありません。通常、CAルートは、理想的にはネットワーク・アクセスがないか最小限で、インターネットに直接アクセスしない完全に分離されたシステムで作成および保守することが適切です。CAルートを中心に実装されるセキュリティ対策は、公開キー・インフラストラクチャ全体のセキュリティにとって重要です。CAルート秘密キーの安全性が損なわれた場合、チェーン全体で署名されたすべての証明書の安全性が損なわれる可能性があります。

組織のCAルートを作成するには、OpenSSLがCA構成および発行する証明書のメタデータのデータベースを管理するために使用できる定義済の構成に従って、ルート・キー・ペアを作成する必要があります。

CAルートを作成するために実行する必要があるステップがいくつかあり、これについては次の手順と例で説明します。

CAディレクトリ構造の作成

CAルートによって管理されるすべての証明書とメタデータは、特定のディレクトリ構造および一部の事前構成済ファイルに格納されます。構造は独自の要件に従って作成する必要がありますが、次の一般的なステップに従ってください。

  1. すべてのCA関連データを格納するディレクトリを作成します。 

    sudo mkdir /root/ca

    このディレクトリは、システムの任意の場所に格納できます。ただし、非常に機密性の高いデータが含まれているため、アクセスが非常に制限された場所に配置するようにしてください。

  2. CAディレクトリに移動して、この手順の後続のすべてのステップを実行します。 

    sudo cd /root/ca

  3. システムのCA証明書、CAデータベースの内容、証明書失効リスト、新しく発行されたすべての証明書および秘密キーを含むディレクトリを作成します。 

    sudo mkdir certs db crl newcerts private

  4. 秘密キーを保護して、それらが格納されているディレクトリへのアクセスが現在のユーザーに制限されるようにします。 

    sudo chmod 700 private

  5. CAデータベースに使用されるファイルを作成します。 

    sudo touch db/index.txt
sudo openssl rand -hex 16  > db/serial
sudo echo 1001 |sudo tee  db/crlnumber
CAルート構成ファイルの作成

CAルート構成を作成し、CA関連のすべてのコンテンツが格納されるディレクトリに格納する必要があります。たとえば、/root/ca/ca-root.confにファイルを作成し、次の内容を移入します。 

[default]
name                    = root-ca
domain_suffix           = example.com
aia_url                 = http://$name.$domain_suffix/$name.crt
crl_url                 = http://$name.$domain_suffix/$name.crl
ocsp_url                = http://ocsp.$name.$domain_suffix:9080
default_ca              = ca_default
name_opt                = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
countryName             = "AU"
organizationName        = "Example Org"
commonName              = "Root CA"

[ca_default]
home                    = .
database                = $home/db/index.txt
serial                  = $home/db/serial
crlnumber               = $home/db/crlnumber
certificate             = $home/$name.crt
private_key             = $home/private/$name.key
RANDFILE                = $home/private/random
new_certs_dir           = $home/certs
unique_subject          = no
copy_extensions         = none
default_days            = 3650
default_crl_days        = 30
default_md              = sha256
policy                  = policy_strict

[policy_strict]
# The root CA should only sign intermediary certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[policy_loose]
# Allow the intermediary CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` manual page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req]
# Standard Req options
default_bits            = 4096
encrypt_key             = yes
default_md              = sha256
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name      = ca_dn
req_extensions          = ca_ext

[ca_ext]
# Extensions for a the CA root (`man x509v3_config`).
basicConstraints        = critical,CA:true
keyUsage                = critical,keyCertSign,cRLSign
subjectKeyIdentifier    = hash

[intermediary_ext]
# Extensions for an intermediary CA.
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[server_ext]
# Extensions for server certificates.
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[client_ext]
# Extensions for client certificates.
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[crl_ext]
# Extension for CRLs.
authorityKeyIdentifier=keyid:always

[ocsp]
# Extension for OCSP signing certificates.
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

前述の例は、OpenSSLで様々な操作を実行する際に役立つ多数のオプション・エントリを含む構成を示しています。最も重要なことは、構成で、証明書に有効な操作のタイプを検証するために様々な証明書タイプに適用できる拡張機能が定義されることです。この構成では、証明書の署名時に適用できる様々なポリシーも定義されます。たとえば、厳密なポリシーを使用して、特定のメタデータが指定されていることを確認し、証明書が署名される場合はCSR内のCA値と一致することを確認できます。このポリシーは、中間CA証明書を生成するために重要です。CAルートまたはいずれかの中間によって署名された他の証明書には、制限の少ないポリシーを適用できます。

この構成ファイル内の様々なセクションの説明は次のとおりです。

  • [default]

    defaultセクションでは、ルート証明書やこのCAの公開済失効リストなどの情報が公開される可能性があるURLなどの基本的な構成情報を定義します。ここでのnameエントリとdomain_suffixエントリは、これらのURLの一部を構成するための変数として使用され、キー・ファイルおよび証明書の名前と参照にも使用されます。これらの値には、システム・ホスト名とシステム・ドメインを使用できます。この構成エントリは、ca_defaultにあるデフォルトのCA構成エントリの場所も参照します。

  • [ca_dn]

    このセクションでは、このCAの識別名に対して生成される証明書のデフォルト値を定義します。これらの値は、CSRと、CSRから生成されたCAルート証明書用の自己署名証明書に書き込まれます。

  • [ca_default]

    このセクションでは、CA全体を制御する構成を指定します。提供されるこの情報は、OpenSSLがファイルを正しく更新し、証明書とキーを正しい場所に格納できるように、このCA用に作成されたディレクトリを構成にマップします。このセクションでは、証明書の有効日数や、証明書失効リストの有効日数など、いくつかのデフォルト値も定義します。この構成はルートCA用であるため、証明書の有効日数を10年に設定できます。これは、ルートCAを変更すると、インフラストラクチャ内の後続のすべての証明書も再発行する必要があるためです。CA(1)マニュアル・ページで、すべての構成ファイル・オプションを表示できます。

  • [policy_strict]

    このセクションでは、中間CA証明書など、一部の証明書に署名するときに従う必要がある厳密なポリシーについて記述します。ポリシーは、証明書内のメタデータに関するルールを定義します。たとえば、国名と組織名がCA証明書と一致するというルールがあります。その他のフィールドはオプションですが、共通名を指定する必要があります。

  • [policy_loose]

    このセクションは、制限の少ないポリシーが許可される、このCAとCA中間によって署名された他の証明書に使用されます。このポリシー・エントリでは、大半のフィールドをオプションにすることができ、共通名のみを指定する必要があります。

  • [req]

    このセクションは、CA証明書リクエストを作成するために1回使用され、証明書リクエストの生成時に使用するデフォルト・オプション(ルートCAのキー長4096ビットなど)を定義します。また、証明書リクエスト内で使用するデフォルト値を取得するために、この構成ファイルのca_dnセクションを参照するCA識別名を指すオプションもあります。

  • [ca_ext]

    この拡張セクションでは、証明書が有効な操作を定義します。ルートCAの場合、すべての中間CA証明書に署名し、基本的に完全な権限を持つためには、この証明書が有効である必要があります。拡張機能の詳細は、X509V3_CONFIG(5)マニュアル・ページを参照してください。

  • [intermediary_ext]

    このセクションは、中間CAとして署名された証明書の個別の拡張構成です。この証明書にはルートCAと同じ権限がありますが、証明書のbasicConstraintsオプション内のpathlen:0で制御される、それ以上の中間CAの証明書に署名することはできません。

  • [server_ext]

    このセクションには、HTTPSやサーバー側メール・サービスなどのサービスに通常使用される、サーバー側の証明書の一般的な拡張オプションが含まれています。これらの証明書は検証と暗号化の目的で発行され、署名権限はありません。この目的で証明書に署名するときに、構成エントリを参照できます。

  • [client_ext]

    このセクションには、ユーザーがシステムへのアクセスを検証および認証するための証明書を提供できる、リモート認証によく使用されるクライアント側の証明書が含まれています。これらの証明書には、使用方法を制御する特定の拡張機能もあります。この構成エントリは、クライアント側の証明書に署名するときに使用して、証明書に正しい拡張機能が適用されるようにすることができます。

  • [crl_ext]

    この拡張機能はCRLの作成時に自動的に適用されますが、この拡張機能は完全性のために提供されています。証明書失効リストの管理を参照してください

  • [ocsp]

    オンライン証明書ステータス・プロトコル(OCSP)は、CRLの代替方法です。OCSPサーバーは、クライアント・ソフトウェアによるリクエストを処理して、署名付き証明書で参照されているリソースから証明書のステータスを取得するように設定できます。この目的のために特別な拡張機能が存在します。詳細は、OCSP(1)マニュアル・ページを参照してください。OCSPサーバーの構成および実行も参照してください。

CAルート・キー・ペアの作成および検証

ca-root.confファイルに指定した構成値を使用して、CAルートの秘密キーと証明書署名リクエストを作成し、秘密キーをprivate/root-ca.keyに保存します。これはインフラストラクチャ全体の最も重要なキーであるため、長い適切なパスフレーズを使用して保護してください。 

sudo openssl req -new -config ca-root.conf -out root-ca.csr -keyout private/root-ca.key

次に、CSRおよびca-root.confファイルを使用して自己署名証明書を作成します。証明書が構成のca_ext部分で定義された拡張機能を使用する必要があることを必ず指定してください。 

sudo openssl ca -selfsign -config ca-root.conf -in root-ca.csr -out root-ca.crt -extensions ca_ext

Using configuration from ca-root.conf
Enter pass phrase for ./private/root-ca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            8f:75:11:1a:8e:33:b2:d1:09:a8:bf:07:9c:67:c8:3e
        Issuer:
            countryName               = AU
            organizationName          = Example Org
            commonName                = Root CA
        Validity
            Not Before: Oct 29 12:23:04 2019 GMT
            Not After : Oct 26 12:23:04 2029 GMT
        Subject:
            countryName               = AU
            organizationName          = Example Org
            commonName                = Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:b9:41:d6:10:36:d4:12:d3:5d:52:29:60:fc:e0:
                    90:34:f6:fb:3e:99:10:33:a1:1d:54:77:3c:11:37:
                    2d:78:c3:3c:3f:40:69:37:fc:de:59:20:c1:1c:07:
                    83:f7:ae:2b:19:03:a7:e8:c6:d6:88:03:b4:ec:60:
                    36:3d:f6:da:59:58:cc:18:18:3e:43:c9:79:11:5b:
                    cf:9e:15:a7:29:fe:dc:4f:7b:0b:93:f0:9a:2b:97:
                    0f:ab:3e:38:7c:e7:c7:d3:5e:34:e2:40:d0:fd:f2:
                    e4:5e:2c:8a:8e:11:83:de:6b:c4:5c:b8:ec:4b:9c:
                    d2:3f:06:3d:53:a6:4b:a6:e3:c6:f6:24:a2:8c:fb:
                    bf:9e:19:d7:60:4b:c5:b6:48:e4:5d:60:4f:2c:47:
                    ca:4a:31:79:bc:7b:5a:25:90:fc:d2:44:a1:79:73:
                    2e:e1:88:a0:73:1f:82:d3:63:3e:67:94:20:f8:be:
                    21:9b:c3:14:4d:3e:9b:19:33:be:9b:cb:e5:54:9f:
                    a7:3f:05:d1:64:56:5f:43:62:65:5b:89:f4:f1:e3:
                    24:e8:1c:d5:03:36:86:ce:9e:76:c7:52:dc:88:f5:
                    d9:87:62:00:82:4d:14:de:a3:60:21:54:12:83:da:
                    8e:8e:5f:63:c3:93:5a:e2:b9:60:16:74:06:c7:46:
                    49:6d:c2:7e:6c:3a:50:3b:bf:c5:d6:20:65:bd:21:
                    a9:ad:b2:1c:4c:13:bf:fd:b8:e1:04:b8:46:c9:6c:
                    29:db:f3:a6:50:3d:2b:9b:83:49:bb:61:c2:8e:94:
                    08:52:84:f2:6d:33:4b:1f:e0:90:ea:a8:ec:d6:ff:
                    97:b8:3d:74:9a:64:d0:f7:22:7d:22:fc:93:47:68:
                    54:63:7c:10:0a:82:2f:84:3f:56:28:cf:8a:03:76:
                    77:b9:db:af:02:6d:b9:36:7e:63:da:f5:d2:a5:6d:
                    54:86:e1:be:f0:e1:54:13:dd:63:0a:53:8e:55:24:
                    90:40:af:f6:38:47:d3:00:0c:ba:66:6a:cc:4b:df:
                    28:fe:02:74:eb:28:15:11:ca:da:a7:86:0f:1f:bd:
                    c4:ac:b9:b1:c7:cc:2a:2a:db:6e:fd:e6:8e:7b:02:
                    17:5e:a7:7d:08:53:e2:a4:69:ca:6b:1f:f1:74:5b:
                    ac:86:2a:f2:b0:80:ea:b7:30:c5:14:c8:12:1e:66:
                    5e:2f:f5:d5:a8:09:39:b4:23:25:fc:ca:35:d5:c0:
                    73:79:a0:8a:12:25:27:ee:f5:ce:9a:97:c0:27:31:
                    ac:21:98:8f:34:25:a5:7a:42:5c:a0:a1:5d:64:39:
                    aa:6a:5e:54:50:5e:ad:c4:fe:c7:93:b1:c0:f7:c9:
                    91:43:93
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
                3C:D9:C3:56:BD:C0:45:83:C8:2B:C7:0F:96:30:CF:2A:55:23:B5:9D
Certificate is to be certified until Oct 26 12:23:04 2029 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

続行するには、秘密キーのパスフレーズを入力するよう求められます。証明書の値が表示された後、証明書に署名するよう求められます。証明書に署名した後、CAデータベースにコミットできます。データベース・ファイルは、公開キー・インフラストラクチャ内のこの証明書をトラッキングするように更新されます。

db/index.txtファイルを表示して、CAルート証明書エントリを表示できます。 

sudo cat db/index.txt

V   291026122304Z        8F75111A8E33B2D109A8BF079C67C83E  unknown /C=AU/O=Example Org/CN=Root CA

データベース索引内の各行に表示される値は、次のとおりです。

  1. ステータス(有効の場合はV、失効の場合はR、期限切れの場合はE)。

  2. YYMMDDHHMMSSZ形式の有効期限。

  3. 失効日または失効しない場合は空(この出力例では、フィールドは空です)。

  4. 16進のシリアル番号。

  5. ファイルの場所、または不明な場合はunknown。

  6. 識別名。

中間CAの作成

インフラストラクチャを作成する次のステップでは、すべてのサーバー証明書とクライアント証明書を処理できる中間CAを作成します。中間CA秘密キーの安全性が損なわれた場合、ルートCAはその証明書を取り消して、その中間によって発行されたその他の証明書を無効にする可能性があるため、これは重要です。

中間CAは、証明書リクエストの大部分の処理に使用されるため、より広いアクセス権を持つ代替サーバー上でホストすることをお薦めします。中間CAはルートCAの正確なモデルですが、それ自体の証明書がルートCAによって署名されることと、署名リクエストを処理するための適切な拡張機能が構成されていることが異なります。

CAディレクトリ構造の作成

中間CAホストで、ルートCAディレクトリ構造を作成するために実行した操作と同じ操作を実行しますが、構成が中間用であることを明確にするために、親ディレクトリに適切に名前を付けます。次に例を示します。

sudo mkdir /root/ca-intermediary
sudo cd /root/ca-intermediary/
sudo mkdir certs db crl newcerts private
sudo chmod 700 private
sudo touch db/index.txt
sudo openssl rand -hex 16  > db/serial
sudo echo 1001 |sudo tee  db/crlnumber
中間CA構成の作成

中間CA構成は、CAルート用に作成した構成とほぼ同じですが、中間に固有のいくつかの変更があります。変更は、次の例のboldのテキストで示されています。 

[default]
name                    = 
                              sub-ca
                           
domain_suffix           = example.com
aia_url                 = http://$name.$domain_suffix/$name.crt
crl_url                 = http://$name.$domain_suffix/$name.crl
ocsp_url                = http://ocsp.$name.$domain_suffix:9080
default_ca              = ca_default
name_opt                = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
countryName             = "AU"
organizationName        = "Example Org"
commonName              = "
                              Intermediary CA
                           "

[ca_default]
home                    = .
database                = $home/db/index.txt
serial                  = $home/db/serial
crlnumber               = $home/db/crlnumber
certificate             = $home/$name.crt
private_key             = $home/private/$name.key
RANDFILE                = $home/private/random
new_certs_dir           = $home/certs
unique_subject          = no
copy_extensions         = none
default_days            = 3650
default_crl_days        = 30
default_md              = sha256
policy                  = policy_strict

[policy_strict]
# The root CA should only sign intermediary certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[policy_loose]
# Allow the intermediary CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` manual page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req]
# Standard Req options
default_bits            = 4096
encrypt_key             = yes
default_md              = sha256
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name      = ca_dn
req_extensions          = intermediary_ext

[ca_ext]
# Extensions for a the CA root (`man x509v3_config`).
basicConstraints        = critical,CA:true
keyUsage                = critical,keyCertSign,cRLSign
subjectKeyIdentifier    = hash

[intermediary_ext]
# Extensions for an intermediary CA.
subjectKeyIdentifier = hash
# authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[server_ext]
# Extensions for server certificates.
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[client_ext]
# Extensions for client certificates.
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[crl_ext]
# Extension for CRLs.
authorityKeyIdentifier=keyid:always

[ocsp]
# Extension for OCSP signing certificates.
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

intermediary_extセクションでは、中間がそれ以上の中間証明書を発行しないため、行がコメント・アウトされていることに注意してください。証明書が署名されるまで、中間は証明書発行者を認識しません。この行が構成にまだ含まれているときにCSRを作成しようとすると、このメタデータをCSRに含める証明書発行者を判別できないため、失敗します。

構成ファイルをintermediary.confとして保存します。

中間CAのCSRの作成

中間証明書のCSRを作成します。 

sudo openssl req -new -config intermediary.conf -out sub-ca.csr -keyout private/sub-ca.key

この証明書は署名証明書でもあるため、パスフレーズで保護して、不正な使用を防ぎ、インフラストラクチャのセキュリティを維持することが重要です。要求されたら、パスフレーズを入力します。

中間CAの署名付き証明書の作成

前のステップで生成したsub-ca.csrを、ルートCAがホストされているシステムの/root/caディレクトリにコピーします。ルートCAホストで、次のコマンドを実行してCSRから署名付き証明書を生成し、中間署名拡張機能を適用します。 

sudo cd /root/ca
sudo openssl ca -config ca-root.conf -in sub-ca.csr -out newcerts/sub-ca.crt \
-extensions intermediary_ext

ルートCAパスフレーズの入力を求められ、証明書の内容が表示され、署名するよう求められます。署名する前に、証明書の内容が適切であることを確認してください。証明書がルートCAによって発行され、サブジェクトに中間CAが含まれていることがわかります。また、正しい拡張機能が証明書に適用されていることも確認できます。

証明書に署名すると、データベースを更新するように求められます。

新しく署名された証明書は、newcerts/sub-ca.crtとして作成されます。

証明書チェーン・ファイルの作成

システムがルートCA証明書を認識していないため、ルートCAの公開証明書と新しく作成した中間CA証明書を含む証明書チェーンを作成する必要があります。この方法では、ホストは、中間CAによって発行される証明書を検証するために、チェーン証明書のコピーのみを必要とします。証明書チェーンを作成するには、ルートCAホストで次のコマンドを実行して、2つの公開証明書を結合します。 

sudo cat root-ca.crt newcerts/sub-ca.crt > newcerts/chained-sub-ca.crt
sudo chmod 444 newcerts/chained-sub-ca.crt

newcerts/sub-ca.crtおよびnewcerts/chained-sub-ca.crt証明書を中間CAホストの/root/ca-intermediary/ディレクトリにコピーします。これで、この証明書を使用して、サーバーとクライアントのCSRを処理し、CRLを生成できるようになりました。

特定のCSRに対して署名証明書を返す場合は、chained-sub-ca.crt証明書を含めることで、証明書が使用されるホストにインストールし、署名証明書を検証する必要があるクライアントに配布できるようにします。

CSRの処理および証明書への署名

システムは、OpenSSLを使用した証明書署名リクエストの作成で説明されているプロセスを使用してCSRを生成するため、署名のためにそれらをCAに送信する必要があります。

サーバー側およびクライアント側の証明書に対する後続のすべてのCSR処理は、環境内で構成された中間CAまたは外部のサード・パーティCAによって実行される必要があります。

CSRを処理するには、それを中間CAホストの/root/ca-intermediaryディレクトリにコピーしてから、openssl caコマンドを使用して適切な拡張構成で署名します。

たとえば、www.example.com.csrという名前のCSRのサーバー側証明書に署名するには、次のコマンドを実行します。 

sudo openssl ca -config intermediary.conf -extensions server_ext -days 375 \
-in www.example.com.csr -out newcerts/www.example.com.crt

証明書を有効にする日数を指定することに注意してください。サーバー側証明書については、日数はCA証明書の有効期間よりも大幅に低い値に制限する必要があります。証明書に適用する正しい拡張機能を選択することが重要です。これらの拡張機能は、構成ファイル内の定義にマップされます。

中間CAキー・パスフレーズの入力を求められた後、証明書に署名してデータベースを更新するように求められます。

証明書をチェーンCA証明書とともに返して、証明書を検証するために配布できるようにする必要があります。

証明書失効リストの管理

証明書失効リストは、署名CAによって発行されて取り消された証明書を識別するために使用されます。このリストは、証明書が取り消された理由も追跡します。

CRLの生成

各CAホストで、証明書を取り消す必要があるときに更新できる空のCRLを作成する必要があります。たとえば、中間CAでは次のコマンドを使用します。 

sudo cd /root/ca-intermediary
sudo openssl ca -config intermediary.conf -gencrl -out crl/sub-ca.crl

CRLは、CAによって取り消された証明書を追跡するために、構成ファイルで定義されているURLに公開する必要があります。可能な場合は、sub-ca.crlを提供するようにWebサービスを構成する必要があります。

CRLの内容は、次のようにして確認できます。 

sudo openssl crl -in crl/sub-ca.crl -noout -text

CRLが作成されたばかりの場合は、空です。default_crl_daysのCA構成ファイルに設定されている構成値に基づいて、新しいCRLを定期的に作成する必要があります。デフォルトでは30日ごとに設定されています。

証明書の取消し

署名付き証明書には、署名CAによって発行されたシリアル番号が含まれています。証明書内のこのシリアル番号は、次のようにして表示できます。 

sudo openssl x509 -serial -noout -in server.crt

このシリアル番号は、CA署名データベース内の証明書を識別し、CAが証明書を取り消せるように、署名したCAによって格納された証明書を識別するためにも使用できます。

証明書が発行されたCAで、certsディレクトリ内でシリアル番号が一致する証明書を見つけることができます。たとえば、中間ホストでは、シリアル番号が8F75111A8E33B2D109A8BF079C67C83Fの証明書の場合、次のようになります。 

sudo cd /root/ca-intermediary
sudo ls certs/8F75111A8E33B2D109A8BF079C67C83F*

certs/8F75111A8E33B2D109A8BF079C67C83F.pem

CAデータベースの証明書の詳細を確認することもできます。 

sudo grep 8F75111A8E33B2D109A8BF079C67C83F db/index.txt

この証明書を取り消すには、署名CAが次のコマンドを発行する必要があります。 

sudo openssl ca -config intermediary.conf -revoke certs/8F75111A8E33B2D109A8BF079C67C83F.pem \
-crl_reason keyCompromise

証明書を取り消す理由は証明書失効リストで使用されるため、この理由を指定する必要があることに注意してください。オプションには、unspecified、keyCompromise、CACompromise、affiliationChanged、superseded、cessationOfOperation、certificateHold,およびremoveFromCRLがあります。詳細は、CA(1)マニュアル・ページを参照してください。

証明書が取り消されると、CAデータベースが更新されてこの変更が反映され、ステータスがdb/index.txtファイルにリストされている証明書のRに設定されます。

データベース・ファイルは、CRLが作成されるたびにCRLを生成するために使用されます。証明書を取り消したらすぐに新しいCRLを生成することをお薦めします。このようにして、このリストは最新の状態に保たれます。詳細は、CRLの生成を参照してください。

OCSPサーバーの構成および実行

オンライン証明書ステータス・プロトコル(OCSP)は、CRLの代替手段であり、独自の発行メカニズムを備えています。OpenSSLには、OCSP問合せに応答できるOCSPサーバーとして実行するオプションが含まれています。

OCSPはCRLより優先されることに注意してください。特にOCSP URLが構成に含まれている場合、このURLはCAによって署名された各証明書に含まれているため、通常、そのCAに対してOCSPサーバーが実行されていることを確認することをお薦めします。クライアント・ソフトウェアは、OCSPサーバーを問い合せることによって、証明書の失効ステータスを確認できます。

任意のCAに対して、OCSPサーバーのキーとCSRを作成します。 

sudo openssl req -new -newkey rsa:2048 -subj "/C=AU/O=Example Org/CN=OCSP Responder" \
-keyout private/ocsp.key -out ocsp.csr

ocsp.csr CSRファイルから署名付き証明書を作成します。 

sudo openssl ca -config intermediary.conf -extensions ocsp -days 187 -in ocsp.csr \
-out newcerts/ocsp.crt

OCSP証明書は失効の処理に対処するため、取り消すことはできません。したがって、証明書の有効期間は管理可能だが比較的短い期間に設定することをお薦めします。この例では、有効期間は187日に設定されています。つまり、6か月ごとにリフレッシュする必要があります。

現在のCAでOCSPサーバーを実行するには、OpenSSL内で提供されているツールを使用できます。たとえば、次のコマンドを使用します。 

sudo openssl ocsp -port 9080 -index db/index.txt -rsigner newcerts/ocsp.crt \
-rkey private/ocsp.key -CA sub-ca.crt -text

このコマンドはCA db/index.txtファイルを直接指定するため、証明書が取り消されると、OCSPサーバーはそれらを自動的に認識します。コマンドを実行すると、OCSPキー・パスフレーズの入力を求められます。サーバーは、プロセスを強制終了するか、[Ctrl]+[C]などの制御シーケンスを使用してエスケープするまで実行を続けます。

ocsp.crtファイルをチェックして、サービスをテストできます。OCSP問合せを実行するには、opensslコマンドを次のように使用します。 

sudo openssl ocsp -issuer sub-ca.crt -CAfile chained-sub-ca.crt -cert newcerts/ocsp.crt \
-url http://127.0.0.1:9080
                        
Response verify OK
newcerts/ocsp.crt: good
        This Update: Oct 30 15:48:11 2019 GMT

前述の例のレスポンスは、検証が成功したかどうかを示し、証明書が失効していない場合はgoodのステータスを示します。失効している場合は、ステータスrevokedが返されます。

OpenSSLを使用した証明書のデバッグおよびテスト

次に示すのは、OpenSSLコマンドを使用して既存の証明書を操作し、インフラストラクチャをデバッグおよびテストする方法を示す例です。ここに示した例は、包括的なものではなく、既存のOpenSSLマニュアル・ページを補足するためのものです。

証明書の調査

X.509証明書に含まれる情報を表示します。 

sudo openssl x509 -text -noout -in server.crt

証明書のSHA1フィンガープリントを表示します。 

sudo openssl x509 -sha1 -noout -fingerprint -in server.crt

署名された証明書のシリアル番号を表示します。 

sudo openssl x509 -serial -noout -in server.crt

秘密キーが証明書と一致することの確認

キーと証明書のモジュラスと公開指数の部分が一致している必要があります。通常、これらの値は長く、チェックが困難です。キーと証明書のモジュラスを比較する最も簡単な方法は、それぞれのMD5ハッシュを作成し、かわりにそれらを比較することです。次に例を示します。 

sudo openssl x509 -noout -modulus -in server.crt | openssl md5
sudo openssl rsa -noout -modulus -in server.key | openssl md5

CSRのモジュラスを同様にチェックして、次のようにキーまたは証明書に一致するかどうかを確認できます。 

sudo openssl req -noout -modulus -in server.csr | openssl md5

キーまたは証明書形式の変更

ブラウザでダウンロードするために、ルート証明書をWebサイトに公開できる形式に変換します。 

sudo openssl x509 -in cert.pem -out rootcert.crt

base64でエンコードされた証明書(PEMまたはRFC 1421とも呼ばれます)をバイナリDER形式に変換します。 

sudo openssl x509 -in cert.pem -outform der -out certificate.der

エンティティとそのCAのbase64でエンコードされた証明書を、単一のPKCS7形式の証明書に変換します。 

sudo openssl crl2pkcs7 -nocrl -certfile entCert.cer -certfile CACert.cer -out certificate.p7b

証明書の一貫性と有効性の確認

署名機関、署名チェーン、有効期間を含む証明書を検証します。 

sudo openssl verify cert.pem

キーの復号化とパスフレーズの追加または削除

暗号化されたキー・ファイルを作成し、そのファイルが暗号化されていない、またはパスフレーズが必要ないと判断した場合は、次のコマンドを実行してファイルを復号化できます。 

sudo openssl rsa -in private.key -out unencrypted.key
                     
Enter pass phrase for private.key:
writing RSA key

private.keyに格納されている暗号化されたキーのパスフレーズの入力を求められ、同じキーの暗号化されていないバージョンがunencrypted.keyファイルに書き込まれます。

暗号化されていないキーを暗号化し、それを保護するためにパスフレーズを追加する場合は、次のコマンドを実行します。 

sudo openssl rsa -aes256 -in unencrypted.key -out private.key

前述の例では、AES暗号が256ビット・キーで使用されています。このコマンドでは、パスフレーズを入力して検証するよう求められます。新しい暗号化されたキー・ファイルがprivate.keyに書き込まれます。

秘密キーのパスフレーズは、対応する公開キーへの影響なく、いつでも追加または削除できます。パスフレーズを追加すると、不正なまたは悪意のあるユーザーが使用できないように秘密キーが保護される一方、不便な点として、秘密キーを使用するサービスを起動または再起動する場合は常に手動介入が必要になります。キーからパスフレーズを削除する場合は、パスフレーズが厳密なアクセス権で格納されていることと、必要としないシステムにコピーされていないことを確認してください。

OpenSSLを使用したSSL/TLS構成済サービスのテスト

ポート443でリスニングするサーバーを構成して、自己署名証明書をテストします。 

sudo openssl s_server -accept 443 -cert cert.pem -key prikey.pem -www

接続のクライアント側をテストします。このコマンドは、HTTPコマンドを直接入力できる証明書などの接続に関する情報を返します。 

sudo openssl s_client -connect server:443 -CAfile cert.pem

次のようにして、サーバーから証明書を抽出します。 

sudo echo | openssl s_client -connect server:443 2>/dev/null | \
sed -ne '/BEGIN CERT/,/END CERT/p' |sudo tee svrcert.pem

OpenSSLを使用したファイルの暗号化および検証

OpenSSLを使用して、任意のファイル・タイプを暗号化または復号化したり、署名してファイルの内容と起点の検証に使用できるダイジェストを作成することもできます。次に、opensslコマンドの使用方法の例を示します。

Blowfishを使用してファイルを暗号化します。 

sudo openssl enc -blowfish -salt -in file -out file.enc

Blowfishで暗号化されたファイルを復号化します。 

sudo openssl enc -d -blowfish -in file.enc -out file.dec

ファイルのSHA1ダイジェストを作成します。 

sudo openssl dgst -sha1 file

ファイルprikey.pemに格納されている秘密キーを使用して、ファイルのSHA1ダイジェストに署名します。 

sudo openssl dgst -sha1 -sign prikey.pem -out file.sha1 file

ファイルpubkey.pemに格納されている公開キーを使用して、ファイルの署名ダイジェストを検証します。 

sudo openssl dgst -sha1 -verify pubkey.pem -signature file.sha1 file

OpenSSLの詳細

OpenSSLの詳細は、openssl(1)、ciphers(1)、dgst(1)、enc(1)、req(1)、s_client(1)、s_server(1)、verify(1)およびx509(1)の各マニュアル・ページを参照してください。