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

이 명령을 사용하여 올바른 형식의 X.509 인증서를 생성 할 수 없습니다. 호스트 이름이 CN (공통 이름 )에 배치 되었기 때문에 형식이 잘못되었습니다 . CN의 호스트 이름 또는 IP 주소를 배치하면 (같은 대부분의 도구를 IETF 모두에 의해 사용되지 않습니다 wget와 curl)과 CA / B 포럼 (CA의 및 브라우저).

IETF 및 CA / B 포럼에 따르면 서버 이름과 IP 주소는 항상 주체 대체 이름 (SAN)에 있습니다. 규칙은 RFC 5280, Internet X.509 공개 키 인프라 인증서 및 CRL (인증서 해지 목록) 프로필 및 CA / 브라우저 포럼 기준 요구 사항을 참조하십시오 .

대부분 OpenSSL 구성 파일을 사용하고 필요에 맞게 조정해야합니다. 아래는 내가 사용하는 예입니다. 이라고 example-com.conf하며을 통해 OpenSSL 명령으로 전달됩니다 -config example-com.conf.

또한 충분히주의 : 모든 기계는 주장 localhost, localhost.localdomain등, 인증서를 발행에주의 localhost. 나는 하지 말라고 말하는 것이 아닙니다 . 관련된 위험이 있음을 이해하십시오.

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

브라우저는 여전히 신뢰할 수있는 루트로 다시 연결 되지 않는 자체 서명 된 인증서에 대한 경고를 표시 합니다. 도구처럼 curl하고 wget불평하지 않습니다,하지만 당신은 여전히 자기 컬의 같은 옵션 서명 당신을 신뢰해야합니다 --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        = test@example.com

# 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) . SAN의 IP 주소와이 인스턴스의 CN 사이의 관계가 무엇인지 잘 모르겠습니다.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

답변

ServerName owncloud.masi

192.168.1.107   owncloud.masi