「OpenSSL」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(en:OpenSSLへの転送ページ)
 
1行目: 1行目:
  +
[[Category:ネットワーク]]
−
#redirect[[en:OpenSSL]]
  
  +
[[Category:セキュリティ]]
  +
[[en:OpenSSL]]
  +
{{Warning|
  +
* OpenSSL 1.0.1 リリースに影響する深刻な脆弱性が2014年4月に公表されました。この脆弱性を利用することで秘密鍵が盗み出される可能性があるため、問題のあるバージョンの OpenSSL を使っていた場合は、秘密鍵と証明書を再生成することが推奨されます。http://heartbleed.com/ や {{Bug|39775}} を参照してください。
  +
* 2015年5月に公開された、OpenSSL のプロトコルの利用に関する共同研究によって、SSL 接続に "Logjam" 攻撃と呼ばれる、さらなる危険が存在することが判明しました。結果については https://weakdh.org/ を、推奨されるサーバー側の設定の変更については https://weakdh.org/sysadmin.html を見て下さい。}}
  +
  +
[http://www.openssl.org OpenSSL] は SSL と TLS プロトコルのオープンソース実装で、OpenSSL と SSLeay ライセンスのデュアルライセンスで配布されています。BSD, Linux, OpenVMS, Solaris, Windows などの様々なプラットフォームをサポートしています。出来る限り柔軟性が確保されるように設計されており、個人利用・商用利用ともに自由に使うことが可能です。先代の SSLeay がベースになっています。OpenSSL のバージョン 1.0.0 は2010年4月29日にリリースされました。
  +
  +
==SSL のイントロダクション==
  +
<!-- Should be moved into [[SSL]] when someone covers other libraries, such as gnutls or the mozilla one. -->
  +
SSL に関する根本的な説明を飛ばして、SSL/TLS のセットアップだけを取り扱うために、この記事では基本的にファイルごとに SSL を説明します。
  +
  +
詳しい情報は [[Wikipedia:ja:認証局]] や [[Wikipedia:ja:公開鍵基盤]] を参照してください。
  +
  +
===認証局 (CA)===
  +
認証局はエンドユーザーからの要求に対して証明書を返します。そのために、返されるエンドユーザーの証明書は CA 秘密鍵と CA 証明書で署名されており、従って CA 公開鍵も含みます。CA は証明書失効リスト (CRL) も配布し、エンドユーザーにもはや有効ではない証明書を通知し、次の CRL の期限を伝えます。
  +
  +
====CA 秘密鍵====
  +
CA 秘密鍵は3つの中で一番重要です。秘密鍵が漏洩してしまうと中央局が許諾を確認したり取り消すという目的が瓦解すると同時に、CA 証明書を証明するのに使われる CA 公開鍵に対する署名済みの鍵ともなります。CA 秘密鍵の署名は CA 証明書自体に埋め込まれているため、漏洩した CA 秘密鍵を使うことで攻撃者は CA 証明書を複製することができてしまいます。
  +
  +
====CA 証明書と公開鍵====
  +
単一のファイルとして全てのエンドユーザーに配布されます。CA 証明書と公開鍵を使うことで、メールサーバーやウェブサイトなど対応する CA によって署名されたとされる他のエンドユーザーの証明書を証明します。
  +
  +
===エンドユーザー===
  +
エンドユーザーは識別名 (DN) を含む証明書の要求をCA に送信します。通常、CA は同一の DN を持つ有効な証明書の発行を許可しません。前の証明書を無効化します。エンドユーザーの証明書は期限日に更新されなかったなどの理由で無効になることがあります。
  +
  +
====エンドユーザー生成鍵====
  +
CA に送信する証明書の要求に署名するためにエンドユーザーは鍵を生成します。CA 秘密鍵と同じように、ユーザーの鍵が漏洩してしまうと攻撃者はユーザーに扮して、ユーザーの名前を使って要求を送信することが可能です。そうなると CA は前の正しいユーザー証明書を無効化してしまいます。
  +
  +
====証明書の要求====
  +
ユーザーの DN と公開鍵を含みます。その名のとおり、CA から証明書を取得する最初のプロセスを表します。
  +
  +
====エンドユーザー証明書====
  +
エンドユーザー証明書と CA 証明書の一番の違いはエンドユーザー証明書は証明書に署名することはできないということです。情報と引き換えに証明する方法を与えるだけです。
  +
  +
====証明書失効リスト (CRL)====
  +
CRL も CA 鍵によって署名されていますが、エンドユーザー証明書に関する情報だけを規定します。通常、新しい CRL が下されるまで30日間のスパンがあります。
  +
  +
==設定==
  +
OpenSSL の設定ファイルは {{ic|/etc/ssl/openssl.cnf}} に置かれることになっており、一見すると複雑なように見えます。設定を分割する ''include'' ディレクティブは存在しません。しかしながら、このセクションでは重要な設定をカバーしています。
  +
  +
シェルスクリプトと同じように、代入で変数を拡張することができます。設定ファイルの形式に関する詳しい説明は ''config(5)'' を見て下さい。オペレーティングシステムによっては、[[man]] ページの名前が ''openssl-config'' や ''config(5ssl)'' になっていることがあります。場合によって、man では読むことができず次の場所にマニュアルが配置されることもあります: {{ic|/usr/share/openssl}}。
  +
  +
===グローバル変数===
  +
以下の設定は全てのセクションに適用されます。そのため、セクションヘッダの下に定義することはできません:
  +
  +
{{bc|<nowiki>
  +
DIR= . # Useful macro for populating real vars.
  +
RANDFILE= ${DIR}/private/.rnd # Entropy source.
  +
default_md= sha1 # Default message digest.
  +
</nowiki>}}
  +
  +
===ca セクション===
  +
以下の設定は CRL に署名したり、証明書に署名、あるいは無効化するときに使われます。リクエストを生成したいだけのユーザーは [[#req セクション]]にスキップできます。
  +
  +
{{bc|<nowiki>
  +
[ ca ]
  +
default_ca= dft_ca # Configuration files may have more than one CA
  +
# section for different scenarios.
  +
  +
[ dft_ca ]
  +
certificate= ${DIR}/cacert.pem # The CA certificate.
  +
database= ${DIR}/index.txt # Keeps tracks of valid/revoked certs.
  +
new_certs_dir= ${DIR}/newcerts # Copies of signed certificates, for
  +
# administrative purposes.
  +
private_key= ${DIR}/private/cakey.pem # The CA key.
  +
serial= ${DIR}/serial # Should be populated with the next
  +
# cert hex serial.
  +
  +
# These govern the way certificates are displayed while confirming
  +
# the signing process.
  +
name_opt= ca_default
  +
cert_opt= ca_default
  +
  +
default_days= 365 # How long to sign certificates for.
  +
default_crl_days=30 # The same, but for CRL.
  +
  +
policy= dft_policy # The default policy should be lenient.
  +
x509_extensions=cert_v3 # For v3 certificates.
  +
  +
[ dft_policy ]
  +
# A value of 'supplied' means the field must be present in the certificate,
  +
# whereas 'match' means the field must be populated with the same contents as
  +
# the CA certificate. 'optional' dictates that the field is entirely optional.
  +
  +
C= supplied # Country
  +
ST= supplied # State or province
  +
L= optional # Locality
  +
O= supplied # Organization
  +
OU= optional # Organizational unit
  +
CN= supplied # Common name
  +
  +
[ cert_v3 ]
  +
# With the exception of 'CA:FALSE', there are PKIX recommendations for end-user
  +
# certificates that should not be able to sign other certificates.
  +
# 'CA:FALSE' is explicitely set because some software will malfunction without.
  +
  +
subjectKeyIdentifier= hash
  +
basicConstraints= CA:FALSE
  +
keyUsage= nonRepudiation, digitalSignature, keyEncipherment
  +
  +
nsCertType= client, email
  +
nsComment= "OpenSSL Generated Certificate"
  +
  +
authorityKeyIdentifier=keyid:always,issuer:always
  +
</nowiki>}}
  +
  +
===req セクション===
  +
鍵やリクエスト、自己署名証明書の生成に関連する設定です。
  +
  +
The req section is responsible for the DN prompts. A general misconception is the ''Common Name'' (CN) prompt, which suggests that it should have the user's proper name as a value. End-user certificates need to have the '''machine hostname''' as CN, whereas CA should ''not'' have a valid TLD, so that there's no chance that, between the possible combinations of certified end-users' CN and the CA certificate's, there's a match that could be misinterpreted by some software as meaning that the end-user certificate is self-signed. Some CA certificates do not even have a CN, such as [http://www.equifax.com Equifax]:
  +
# subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
  +
openssl x509 -subject -noout < /etc/ssl/certs/Equifax_Secure_CA.pem
  +
  +
Even though splitting the files isn't strictly necessary to normal functioning, it is very confusing to handle request generation and CA administration from the same configuration file, so it is advised to follow the convention of clearly separating the settings into two {{ic|cnf}} files and into two containing directories.
  +
  +
Here are the settings that are common to both tasks:
  +
  +
{{bc|<nowiki>
  +
[ req ]
  +
# Default bit encryption and out file for generated keys.
  +
default_bits= 2048
  +
default_keyfile=private/cakey.pem
  +
  +
string_mask= utf8only # Only allow utf8 strings in request/ca fields.
  +
prompt= no # Do not prompt for field value confirmation.
  +
</nowiki>}}
  +
  +
====CA req 設定====
  +
The settings should produce a standard CA capable of only singing other certificates:
  +
  +
{{bc|<nowiki>
  +
distinguished_name=ca_dn # Distinguished name contents.
  +
x509_extensions=ca_v3 # For generating ca certificates.
  +
  +
[ ca_dn ]
  +
# CN isn't needed for CA certificates
  +
C= US
  +
ST= New Jersey
  +
O= localdomain
  +
  +
[ ca_v3 ]
  +
subjectKeyIdentifier= hash
  +
  +
# PKIX says this should also contain the 'crucial' value, yet some programs
  +
# have trouble handling it.
  +
basicConstraints= CA:TRUE
  +
  +
keyUsage= cRLSign, keyCertSign
  +
  +
nsCertType= sslCA
  +
nsComment= "OpenSSL Generated CA Certificate"
  +
  +
authorityKeyIdentifier=keyid:always,issuer:always
  +
</nowiki>}}
  +
  +
====エンドユーザー req 設定====
  +
Makes a v3 request suitable for most circumstances:
  +
  +
{{bc|<nowiki>
  +
distinguished_name=ca_dn # Distinguished name contents.
  +
req_extensions=req_v3 # For generating ca certificates.
  +
  +
[ ca_dn ]
  +
C= US
  +
ST= New Jersey
  +
O= localdomain
  +
CN= localhost
  +
  +
[ req_v3 ]
  +
basicConstraints= CA:FALSE
  +
keyUsage= nonRepudiation, digitalSignature, keyEncipherment
  +
</nowiki>}}
  +
  +
===GOST エンジンのサポート===
  +
First, be sure that libgost.so exist on your system
  +
pacman -Ql openssl | grep libgost
  +
  +
In case everything is fine, add the following lines to the config:
  +
openssl_conf = openssl_def # this must be a top-level declaration
  +
  +
Put the following lines in the end of the document:
  +
[ openssl_def ]
  +
engines = engine_section
  +
  +
[ engine_section ]
  +
gost = gost_section
  +
  +
[ gost_section ]
  +
engine_id = gost
  +
soft_load = 1
  +
dynamic_path = /usr/lib/engines/libgost.so
  +
default_algorithms = ALL
  +
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
  +
The official [http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/crypto/external/bsd/openssl/dist/engines/ccgost/README.gost README.gost] should contain more examples on this.
  +
  +
==鍵の生成==
  +
Before generating the key, make a secure directory to host it:
  +
mkdir -m0700 private
  +
Followed by preemptively assigning secure permissions for the key itself:
  +
touch private/key.pem
  +
chmod 0600 private/key.pem
  +
  +
An example {{ic|genpkey}} key generation:
  +
openssl genpkey -algorithm RSA -out private/key.pem -pkeyopt rsa_keygen_bits:4096
  +
  +
If an encrypted key is desired, use the following command. Password will be prompted for:
  +
openssl genpkey -aes-256-cbc -algorithm RSA -out private/key.pem -pkeyopt rsa_keygen_bits:4096
  +
  +
==要求の作成==
  +
To obtain a certificate from a CA, whether it be a public one such as [http://www.cacert.org CAcert.org], or a locally managed solution, a request file must be delivered to the CA, and these are conventionally called {{ic|csr}} files.
  +
  +
Make a new request and sign it with a previously [[#Generating keys|generated key]]:
  +
openssl req -new -sha256 -key private/key.pem -out req.csr
  +
  +
==証明書の署名==
  +
Covers the process of local CA signing: directly self-signed certificates or through a local CA.
  +
  +
===自己署名証明書===
  +
A significant amount of programs will not work with self-signed certificates, and maintaining more than one system with self-signed certificates is more trouble than investing the initial effort in setting up a [[#Certificate authority|certificate authority]].
  +
  +
If a key was already generated as [[#Generating keys|explained before]], use this command to sign the new certificate with the aforementioned key:
  +
openssl req -key private/key.pem -x509 -new -days 3650 -out cacert.pem
  +
  +
===認証局===
  +
The method shown in this section is mostly meant to show how signing works; it is not suited for large deployments that need to automate signing a large number of certificates. Consider installing an SSL server for that purpose.
  +
  +
Before using the Makefile, make a configuration file according to [[#Configuring]]. Be sure to follow instructions relevant to CA administration; not request generation.
  +
  +
====Makefile====
  +
Saving the file as {{ic|Makefile}} and issuing {{Ic|make}} in the containing directory will generate the initial CRL along with its prerequisites:
  +
  +
{{bc|<nowiki>
  +
OPENSSL= openssl
  +
CNF= openssl.cnf
  +
CA= ${OPENSSL} ca -config ${CNF}
  +
REQ= ${OPENSSL} req -config ${CNF}
  +
  +
KEY= private/cakey.pem
  +
KEYMODE= RSA
  +
  +
CACERT= cacert.pem
  +
CADAYS= 3650
  +
  +
CRL= crl.pem
  +
INDEX= index.txt
  +
SERIAL= serial
  +
  +
  +
CADEPS= ${CNF} ${KEY} ${CACERT}
  +
  +
all: ${CRL}
  +
  +
${CRL}: ${CADEPS}
  +
${CA} -gencrl -out ${CRL}
  +
  +
${CACERT}: ${CNF} ${KEY}
  +
${REQ} -key ${KEY} -x509 -new -days ${CADAYS} -out ${CACERT}
  +
rm -f ${INDEX}
  +
touch ${INDEX}
  +
echo 100001 > ${SERIAL}
  +
  +
${KEY}: ${CNF}
  +
mkdir -m0700 -p $(dir ${KEY})
  +
touch ${KEY}
  +
chmod 0600 ${KEY}
  +
${OPENSSL} genpkey -algorithm ${KEYMODE} -out ${KEY}
  +
  +
  +
revoke: ${CADEPS} ${item}
  +
@test -n $${item:?'usage: ${MAKE} revoke item=cert.pem'}
  +
${CA} -revoke ${item}
  +
${MAKE} ${CRL}
  +
  +
sign: ${CADEPS} ${item}
  +
@test -n $${item:?'usage: ${MAKE} sign item=request.csr'}
  +
mkdir -p newcerts
  +
${CA} -in ${item} -out ${item:.csr=.crt}
  +
</nowiki>}}
  +
  +
To sign certificates:
  +
make sign item='''req.csr'''
  +
  +
To revoke certificates:
  +
make revoke item='''cert.pem'''
  +
  +
==参照==
  +
* [http://en.wikipedia.org/wiki/OpenSSL Wikipedia page] on OpenSSL, with background information.
  +
* [http://www.openssl.org OpenSSL] プロジェクトページ
  +
* [https://www.freebsd.org/doc/ja/books/handbook/openssl.html FreeBSD ハンドブック]
  +
* [http://www.akadia.com/services/ssh_test_certificate.html Step-by-step guide to create a signed SSL certificate]

2015年12月3日 (木) 23:46時点における版

警告:
  • OpenSSL 1.0.1 リリースに影響する深刻な脆弱性が2014年4月に公表されました。この脆弱性を利用することで秘密鍵が盗み出される可能性があるため、問題のあるバージョンの OpenSSL を使っていた場合は、秘密鍵と証明書を再生成することが推奨されます。http://heartbleed.com/ や FS#39775 を参照してください。
  • 2015年5月に公開された、OpenSSL のプロトコルの利用に関する共同研究によって、SSL 接続に "Logjam" 攻撃と呼ばれる、さらなる危険が存在することが判明しました。結果については https://weakdh.org/ を、推奨されるサーバー側の設定の変更については https://weakdh.org/sysadmin.html を見て下さい。

OpenSSL は SSL と TLS プロトコルのオープンソース実装で、OpenSSL と SSLeay ライセンスのデュアルライセンスで配布されています。BSD, Linux, OpenVMS, Solaris, Windows などの様々なプラットフォームをサポートしています。出来る限り柔軟性が確保されるように設計されており、個人利用・商用利用ともに自由に使うことが可能です。先代の SSLeay がベースになっています。OpenSSL のバージョン 1.0.0 は2010年4月29日にリリースされました。

SSL のイントロダクション

SSL に関する根本的な説明を飛ばして、SSL/TLS のセットアップだけを取り扱うために、この記事では基本的にファイルごとに SSL を説明します。

詳しい情報は Wikipedia:ja:認証局 や Wikipedia:ja:公開鍵基盤 を参照してください。

認証局 (CA)

認証局はエンドユーザーからの要求に対して証明書を返します。そのために、返されるエンドユーザーの証明書は CA 秘密鍵と CA 証明書で署名されており、従って CA 公開鍵も含みます。CA は証明書失効リスト (CRL) も配布し、エンドユーザーにもはや有効ではない証明書を通知し、次の CRL の期限を伝えます。

CA 秘密鍵

CA 秘密鍵は3つの中で一番重要です。秘密鍵が漏洩してしまうと中央局が許諾を確認したり取り消すという目的が瓦解すると同時に、CA 証明書を証明するのに使われる CA 公開鍵に対する署名済みの鍵ともなります。CA 秘密鍵の署名は CA 証明書自体に埋め込まれているため、漏洩した CA 秘密鍵を使うことで攻撃者は CA 証明書を複製することができてしまいます。

CA 証明書と公開鍵

単一のファイルとして全てのエンドユーザーに配布されます。CA 証明書と公開鍵を使うことで、メールサーバーやウェブサイトなど対応する CA によって署名されたとされる他のエンドユーザーの証明書を証明します。

エンドユーザー

エンドユーザーは識別名 (DN) を含む証明書の要求をCA に送信します。通常、CA は同一の DN を持つ有効な証明書の発行を許可しません。前の証明書を無効化します。エンドユーザーの証明書は期限日に更新されなかったなどの理由で無効になることがあります。

エンドユーザー生成鍵

CA に送信する証明書の要求に署名するためにエンドユーザーは鍵を生成します。CA 秘密鍵と同じように、ユーザーの鍵が漏洩してしまうと攻撃者はユーザーに扮して、ユーザーの名前を使って要求を送信することが可能です。そうなると CA は前の正しいユーザー証明書を無効化してしまいます。

証明書の要求

ユーザーの DN と公開鍵を含みます。その名のとおり、CA から証明書を取得する最初のプロセスを表します。

エンドユーザー証明書

エンドユーザー証明書と CA 証明書の一番の違いはエンドユーザー証明書は証明書に署名することはできないということです。情報と引き換えに証明する方法を与えるだけです。

証明書失効リスト (CRL)

CRL も CA 鍵によって署名されていますが、エンドユーザー証明書に関する情報だけを規定します。通常、新しい CRL が下されるまで30日間のスパンがあります。

設定

OpenSSL の設定ファイルは /etc/ssl/openssl.cnf に置かれることになっており、一見すると複雑なように見えます。設定を分割する include ディレクティブは存在しません。しかしながら、このセクションでは重要な設定をカバーしています。

シェルスクリプトと同じように、代入で変数を拡張することができます。設定ファイルの形式に関する詳しい説明は config(5) を見て下さい。オペレーティングシステムによっては、man ページの名前が openssl-config や config(5ssl) になっていることがあります。場合によって、man では読むことができず次の場所にマニュアルが配置されることもあります: /usr/share/openssl。

グローバル変数

以下の設定は全てのセクションに適用されます。そのため、セクションヘッダの下に定義することはできません: 

DIR=		.			# Useful macro for populating real vars.
RANDFILE=	${DIR}/private/.rnd	# Entropy source.
default_md=	sha1			# Default message digest.

ca セクション

以下の設定は CRL に署名したり、証明書に署名、あるいは無効化するときに使われます。リクエストを生成したいだけのユーザーは #req セクションにスキップできます。 

[ ca ]
default_ca=	dft_ca	# Configuration files may have more than one CA
			# section for different scenarios.

[ dft_ca ]
certificate=	${DIR}/cacert.pem	# The CA certificate.
database=	${DIR}/index.txt	# Keeps tracks of valid/revoked certs.
new_certs_dir=	${DIR}/newcerts		# Copies of signed certificates, for
					# administrative purposes.
private_key=	${DIR}/private/cakey.pem # The CA key.
serial=		${DIR}/serial		# Should be populated with the next
					# cert hex serial.

# These govern the way certificates are displayed while confirming
# the signing process.
name_opt=	ca_default
cert_opt=	ca_default

default_days=	365	# How long to sign certificates for.
default_crl_days=30	# The same, but for CRL.

policy=		dft_policy	# The default policy should be lenient.
x509_extensions=cert_v3		# For v3 certificates.

[ dft_policy ]
# A value of 'supplied' means the field must be present in the certificate,
# whereas 'match' means the field must be populated with the same contents as
# the CA certificate. 'optional' dictates that the field is entirely optional.

C=	supplied	# Country
ST=	supplied	# State or province
L=	optional	# Locality
O=	supplied	# Organization
OU=	optional	# Organizational unit
CN=	supplied	# Common name

[ cert_v3 ]
# With the exception of 'CA:FALSE', there are PKIX recommendations for end-user
# certificates that should not be able to sign other certificates.
# 'CA:FALSE' is explicitely set because some software will malfunction without.

subjectKeyIdentifier=	hash
basicConstraints=	CA:FALSE
keyUsage=		nonRepudiation, digitalSignature, keyEncipherment

nsCertType=		client, email
nsComment=		"OpenSSL Generated Certificate"

authorityKeyIdentifier=keyid:always,issuer:always

req セクション

鍵やリクエスト、自己署名証明書の生成に関連する設定です。

The req section is responsible for the DN prompts. A general misconception is the Common Name (CN) prompt, which suggests that it should have the user's proper name as a value. End-user certificates need to have the machine hostname as CN, whereas CA should not have a valid TLD, so that there's no chance that, between the possible combinations of certified end-users' CN and the CA certificate's, there's a match that could be misinterpreted by some software as meaning that the end-user certificate is self-signed. Some CA certificates do not even have a CN, such as Equifax: 

# subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
openssl x509 -subject -noout < /etc/ssl/certs/Equifax_Secure_CA.pem

Even though splitting the files isn't strictly necessary to normal functioning, it is very confusing to handle request generation and CA administration from the same configuration file, so it is advised to follow the convention of clearly separating the settings into two cnf files and into two containing directories.

Here are the settings that are common to both tasks: 

[ req ]
# Default bit encryption and out file for generated keys.
default_bits=	2048
default_keyfile=private/cakey.pem

string_mask=	utf8only	# Only allow utf8 strings in request/ca fields.
prompt=		no		# Do not prompt for field value confirmation.

CA req 設定

The settings should produce a standard CA capable of only singing other certificates: 

distinguished_name=ca_dn	# Distinguished name contents.
x509_extensions=ca_v3		# For generating ca certificates.

[ ca_dn ]
# CN isn't needed for CA certificates
C=	US
ST=	New Jersey
O=	localdomain

[ ca_v3 ]
subjectKeyIdentifier=	hash

# PKIX says this should also contain the 'crucial' value, yet some programs
# have trouble handling it.
basicConstraints=	CA:TRUE

keyUsage=	cRLSign, keyCertSign

nsCertType=	sslCA
nsComment=	"OpenSSL Generated CA Certificate"

authorityKeyIdentifier=keyid:always,issuer:always

エンドユーザー req 設定

Makes a v3 request suitable for most circumstances: 

distinguished_name=ca_dn	# Distinguished name contents.
req_extensions=req_v3		# For generating ca certificates.

[ ca_dn ]
C=	US
ST=	New Jersey
O=	localdomain
CN=	localhost

[ req_v3 ]
basicConstraints=	CA:FALSE
keyUsage=		nonRepudiation, digitalSignature, keyEncipherment

GOST エンジンのサポート

First, be sure that libgost.so exist on your system 

pacman -Ql openssl | grep libgost

In case everything is fine, add the following lines to the config: 

openssl_conf = openssl_def # this must be a top-level declaration

Put the following lines in the end of the document: 

[ openssl_def ]
engines = engine_section

[ engine_section ]
gost = gost_section

[ gost_section ]
engine_id = gost
soft_load = 1
dynamic_path = /usr/lib/engines/libgost.so
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

The official README.gost should contain more examples on this.

鍵の生成

Before generating the key, make a secure directory to host it: 

mkdir -m0700 private

Followed by preemptively assigning secure permissions for the key itself: 

touch private/key.pem
chmod 0600 private/key.pem

An example genpkey key generation: 

openssl genpkey -algorithm RSA -out private/key.pem -pkeyopt rsa_keygen_bits:4096

If an encrypted key is desired, use the following command. Password will be prompted for: 

openssl genpkey -aes-256-cbc -algorithm RSA -out private/key.pem -pkeyopt rsa_keygen_bits:4096

要求の作成

To obtain a certificate from a CA, whether it be a public one such as CAcert.org, or a locally managed solution, a request file must be delivered to the CA, and these are conventionally called csr files.

Make a new request and sign it with a previously generated key: 

openssl req -new -sha256 -key private/key.pem -out req.csr

証明書の署名

Covers the process of local CA signing: directly self-signed certificates or through a local CA.

自己署名証明書

A significant amount of programs will not work with self-signed certificates, and maintaining more than one system with self-signed certificates is more trouble than investing the initial effort in setting up a certificate authority.

If a key was already generated as explained before, use this command to sign the new certificate with the aforementioned key: 

openssl req -key private/key.pem -x509 -new -days 3650 -out cacert.pem

認証局

The method shown in this section is mostly meant to show how signing works; it is not suited for large deployments that need to automate signing a large number of certificates. Consider installing an SSL server for that purpose.

Before using the Makefile, make a configuration file according to #Configuring. Be sure to follow instructions relevant to CA administration; not request generation.

Makefile

Saving the file as Makefile and issuing make in the containing directory will generate the initial CRL along with its prerequisites: 

OPENSSL=	openssl
CNF=		openssl.cnf
CA=		${OPENSSL} ca -config ${CNF}
REQ=		${OPENSSL} req -config ${CNF}

KEY=		private/cakey.pem
KEYMODE=	RSA

CACERT=		cacert.pem
CADAYS=		3650

CRL=		crl.pem
INDEX=		index.txt
SERIAL=		serial


CADEPS=		${CNF} ${KEY} ${CACERT}

all:	${CRL}

${CRL}:	${CADEPS}
	${CA} -gencrl -out ${CRL}

${CACERT}: ${CNF} ${KEY}
	${REQ} -key ${KEY} -x509 -new -days ${CADAYS} -out ${CACERT}
	rm -f ${INDEX}
	touch ${INDEX}
	echo 100001 > ${SERIAL}

${KEY}: ${CNF}
	mkdir -m0700 -p $(dir ${KEY})
	touch ${KEY}
	chmod 0600 ${KEY}
	${OPENSSL} genpkey -algorithm ${KEYMODE} -out ${KEY}


revoke:	${CADEPS} ${item}
	@test -n $${item:?'usage: ${MAKE} revoke item=cert.pem'}
	${CA} -revoke ${item}
	${MAKE} ${CRL}

sign:	${CADEPS} ${item}
	@test -n $${item:?'usage: ${MAKE} sign item=request.csr'}
	mkdir -p newcerts
	${CA} -in ${item} -out ${item:.csr=.crt}

To sign certificates: 

make sign item=req.csr

To revoke certificates: 

make revoke item=cert.pem

参照

「https://wiki.archlinux.jp/index.php?title=OpenSSL&oldid=4220」から取得