openssl req -x509 -days 365 -newkey rsa: 2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt
Você não pode usar este comando para gerar um certificado X.509 bem formado. Ele ficará mal formado porque o nome do host é colocado no Common Name (CN) . A colocação de um nome de host ou endereço IP na CN é preterida pelo IETF (a maioria das ferramentas, como wget
e curl
) e pelos Fóruns da CA / B (CA e navegadores).
De acordo com os Fóruns IETF e CA / B, os nomes dos servidores e os endereços IP sempre aparecem no nome alternativo do assunto (SAN) . Para obter as regras, consulte RFC 5280, Perfil de infraestrutura de chave pública da Internet X.509 e perfil da lista de revogação de certificados (CRL) e requisitos de linha de base do fórum do CA / Browser .
Você precisa principalmente usar um arquivo de configuração do OpenSSL e adaptá-lo às suas necessidades. Abaixo está um exemplo de um que eu uso. É chamado example-com.conf
e passado ao comando OpenSSL via -config example-com.conf
.
Além disso , note bem : todas as máquinas a pretensão de ser localhost
, localhost.localdomain
etc. Tenha cuidado com a emissão de certificados para localhost
. Estou não dizendo não fazê-lo; apenas entenda que existem alguns riscos envolvidos.
As alternativas localhost
são: (1) executar o DNS e emitir certificados para o nome DNS da máquina. Ou (2) use IP estático e inclua o endereço IP estático.
Os Navegadores ainda fornecerão avisos sobre um certificado autoassinado que não retorne a uma raiz confiável. Ferramentas gostam curl
e wget
não reclamam, mas você ainda precisa confiar em você mesmo com uma opção como cURL --cafile
. Para superar o problema de confiança do navegador, você precisa se tornar seu próprio CA.
"Tornar-se seu próprio CA" é conhecido como executar uma PKI privada. Não há muito nisso. Você pode fazer tudo o que uma CA pública pode fazer. A única coisa diferente é que você precisará instalar seu certificado CA raiz nas várias lojas. Não é diferente do que, digamos, usar cURL's cacerts.pm
. cacerts.pm
é apenas uma coleção de Root CAs e agora você se juntou ao clube.
Se você se tornar seu próprio CA, grave sua chave privada da CA Raiz em disco e mantenha-a offline. Em seguida, coloque-o na sua unidade de CD / DVD quando precisar assinar uma solicitação de assinatura. Agora você está emitindo certificados como uma CA pública.
Nada disso é terrivelmente difícil depois que você assina uma ou duas solicitações de assinatura. Eu tenho um PKI particular há anos em casa. Todos os meus dispositivos e gadgets confiam na minha CA.
Para obter mais informações sobre como se tornar sua própria CA, consulte Como assinar uma solicitação de assinatura de certificado com sua autoridade de certificação e Como criar um certificado autoassinado com openssl? .
Dos comentários no arquivo de configuração abaixo ...
Autoassinado (observe a adição de -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
Solicitação de assinatura (observe a falta de -x509)
openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
Imprimir um autoassinado
openssl x509 -in example-com.cert.pem -text -noout
Imprimir uma solicitação de assinatura
openssl req -in example-com.req.pem -text -noout
Arquivo de configuração
# 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
Pode ser necessário fazer o seguinte no Chrome. Caso contrário, o Chrome poderá reclamar que um Nome Comum é inválido ( ERR_CERT_COMMON_NAME_INVALID
) . Não tenho certeza de qual é a relação entre um endereço IP na SAN e uma CN nessa instância.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
Centos 7 / Vagrant / Chrome Browser
.