localhost에 대한 자체 서명 인증서를 만드는 방법은 무엇입니까?

openssl req -x509 -days 365 -newkey rsa:2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt

이 명령을 사용하여 올바른 형식의 X.509 인증서를 생성할 수 없습니다. 호스트 이름이 다음 위치에 있으므로 형식이 잘못되었습니다.통칭(중국어). IETF( wget및 등의 대부분의 도구 curl)나 CA/B 포럼(CA 및 브라우저) 모두 CN에 호스트 이름이나 IP 주소 배치를 지원하지 않습니다.

IETF 및 CA/B 포럼에 따르면 서버 이름과 IP 주소는 항상 다음 위치에 있습니다.주체 대체 이름(SAN). 규칙 보기RFC 5280, 인터넷 X.509 공개 키 인프라 인증서 및 CRL(인증서 해지 목록) 프로필그리고CA/브라우저 포럼 벤치마크 요구 사항.

기본적으로 OpenSSL 구성 파일을 사용하고 필요에 맞게 사용자 정의해야 합니다. 아래는 내가 사용하는 예입니다. 이는 호출되어 example-com.confOpenSSL 명령으로 전달됩니다 -config example-com.conf.

---

반품집중 해주세요: 모든 기계는 다음과 같이 주장합니다 localhost. localhost.localdomain인증서를 발급할 때는 주의하세요 localhost. 그래요아니요하지 마세요. 위험이 따른다는 점만 이해하세요.

대안 은 다음 localhost과 같습니다. (1) DNS를 실행하고 컴퓨터의 DNS 이름에 대한 인증서를 발급합니다. 또는 (2) 고정 IP를 사용하고 고정 IP 주소를 포함합니다.

---

브라우저는 자체 서명된 인증서에 대해 계속 경고합니다.확실히신뢰할 수 있는 루트에 다시 연결합니다. curl와 같은 도구는 wget불평하지 않지만 여전히 cURL 과 같은 옵션을 사용하여 자체 서명하고 있다는 것을 신뢰해야 합니다 --cafile. 브라우저 신뢰 문제를 해결하려면 자체 CA가 되어야 합니다.

"자신만의 CA가 되어 보세요"이를 개인 PKI 실행이라고 합니다. 할 말이 없습니다. 공용 CA가 할 수 있는 모든 작업을 수행할 수 있습니다. 유일한 차이점은 설치가 필요하다는 것입니다.당신의다양한 저장소의 루트 CA 인증서. 이는 cURL을 사용하는 것과 동일합니다 cacerts.pm. cacerts.pm루트 CA 모음이며 이제 클럽에 가입했습니다.

자체 CA가 된 경우 루트 CA 개인 키를 디스크에 굽고 오프라인으로 유지해야 합니다. 그런 다음 서명 요청에 서명해야 할 때 이를 CD/DVD 드라이브에 넣습니다. 이제 공용 CA처럼 인증서를 발급합니다.

서명 요청에 서명한 후에는 이 중 어느 것도 특별히 어렵지 않습니다. 저는 수년 동안 집에서 개인 PKI를 운영해 왔습니다. 내 모든 장치와 가젯은 내 CA를 신뢰합니다.

자체 CA가 되는 방법에 대한 자세한 내용은 다음을 참조하세요.인증 기관을 통해 인증서 서명 요청에 서명하는 방법그리고openssl을 사용하여 자체 서명된 인증서를 만드는 방법은 무엇입니까?.

---

아래 구성 파일의 주석에서 ...

자체 서명됨(-x509 추가 참고)

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem

서명 요청(참고 누락 -x509)

openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem

자체 서명 인쇄

openssl x509 -in example-com.cert.pem -text -noout

서명 요청 인쇄

openssl req -in example-com.req.pem -text -noout

구성 파일

# Self Signed (note the addition of -x509):
#     openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem
# Signing Request (note the lack of -x509):
#     openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
# Print it:
#     openssl x509 -in example-com.cert.pem -text -noout
#     openssl req -in example-com.req.pem -text -noout

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   It's sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you 
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = [email protected]

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

#  If RSA Key Transport bothers you, then remove keyEncipherment. TLS 1.3 is removing RSA
#  Key Transport in favor of exchanges with Forward Secrecy, like DHE and ECDHE.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# extendedKeyUsage  = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# extendedKeyUsage  = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1
# DNS.9     = fe80::1

---

Chrome의 경우 다음을 수행해야 할 수도 있습니다. 그렇지 않으면Chrome이 불만을 표시할 수 있음일반 이름유효하지 않습니다( ERR_CERT_COMMON_NAME_INVALID). 이 예에서는 IP 주소와 SAN의 CN 사이에 어떤 관계가 있는지 잘 모르겠습니다.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

HTTP 요청의 CommonName헤더로 전송된 내용과 일치 해야 합니다. Host:귀하의 경우에는 그게 전부입니다 192.168.1.107 (후행 슬래시 제외).

웹 서버의 호스트 이름 구성

개인적으로 저는 웹 서버에 친숙한 호스트 이름을 구성하겠습니다. 메일 Apache 구성 또는 가상 호스트 구성( /etc/apache2/sites-enabled/000-default.confDebian 기반 배포판에 있을 수 있음) 에서 ServerName또는 ServerAlias지시어를 사용합니다. 예를 들면 다음과 같습니다.

ServerName owncloud.masi

Apache를 다시 시작하고 DNS를 구성하거나 (더 쉽게) 각 클라이언트에 항목을 추가하여 /etc/hosts올바른 IP 주소를 가리키도록 합니다.

192.168.1.107   owncloud.masi