Todos os artigos que leio on-line falam sobre a criação de um certificado auto-assinado para um domínio que você possui.
Eu tenho o Apache2 configurado em um servidor Ubuntu 16.04 em casa. Meu ISP me dá um IP dinâmico, então eu uso o No-IP. Tenho portas abertas no meu roteador para redirecionar o tráfego para o meu servidor.
Eu também acesso o servidor web de casa (dentro da rede).
Então, se eu estiver fora da minha rede doméstica, usarei o link e, se estiver em casa, usarei link .
Então, como posso criar um certificado autoassinado para essa situação? O que eu coloco como nome comum?
Para responder à sua pergunta real:
Você precisa examinar os nomes alternativos de assunto.
Isso permite que um certificado tenha mais de um nome de domínio atribuído a eles.
A recomendação é que você deixe o Nome Comum vazio e liste todos os FQDNs no Nome Alternativo do Assunto.
Como alternativa, você pode colocar qualquer um dos seus nomes no Nome Comum, mas ainda deve listá-los todos em Nomes Alternativos de Assunto.
Sugira que você gaste US $ 10 ou menos em um nome de domínio e use um certificado gratuito Vamos criptografar . Você terá menos problemas. Você pode conseguir um certificado usando o domínio noip.me também.
Vamos criptografar é muito fácil de configurar em uma distribuição Linux suportada com Apache / Nginx, mas você não disse qual sistema operacional está usando. Se você editar sua postagem acima, poderei dar mais orientações.
Você pode aplicar um truque e usar um certificado curinga para '* .noip.com'.
Isso requer que você use 'homeserver.noip.com' e que o endereço aponte para o seu IP local, o que você pode fazer adicionando uma entrada ao arquivo hosts nas máquinas onde você usa 'homeserver.noip.com'.
'username.noip.com' ainda seria resolvido da maneira habitual.
É uma abordagem um pouco "suja", mas parece eficiente para as suas necessidades.
What do I put as the Common Name?
Você usa um nome amigável para o Common Name (CN) por dois motivos. Primeiro, é exibido para os usuários por ferramentas, então você quer algo como Exemplo Widgets, LLC . Segundo, os nomes de host sempre entram no Nome Alternativo de Assunto (SAN) . Colocar um nome de host no CN é reprovado pelos Fóruns IETF e CA / B.
Para mais regras e motivos, consulte Como você assina a Solicitação de assinatura de certificado com sua autoridade de certificação e Como criar um certificado autoassinado com o openssl?
So how can I create a self-signed certificate for this situation?
Use o utilitário openssl com um arquivo de configuração personalizado. Abaixo está uma amostra.
Você deve duas coisas. Primeiro, altere a lista de nomes DNS para username.noip.me e homeserver . Em segundo lugar, depois de alterar os nomes desejados no certificado, execute o seguinte comando:
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
Obviamente, você pode alterar o nome do arquivo de configuração de example-com.conf para o que você quiser.
Além disso, em casa, eu corro meu próprio PKI. Eu tenho uma CA raiz que emite certificados para dispositivos na minha rede quando necessário. Todos os dispositivos têm a CA raiz instalada. Meu domínio interno é chamado home.pvt . Os hosts da rede são denominados pine64.home.pvt , rpi3.home.pvt , solaris.home.pvt , windows10.home.pvt etc. Tudo funciona conforme o esperado.
Exemplo de 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).
# Its 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 its 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 ...
# 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.
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
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
Tags ssl openssl https dynamic-dns