Está a escapar-me alguma coisa? Esta é a maneira correta de construir um certificado autossignado?

É fácil criar um certificado autossignado. Basta usar o comando openssl req. Pode ser complicado criar um que possa ser consumido pela maior seleção de clientes, como navegadores e ferramentas de linha de comando. É difícil porque os navegadores têm os seus próprios requisitos e são mais restritivos do que a IETF. Os requisitos utilizados pelos navegadores são: documentado no CA / Browser Forums (ver referências abaixo). As restrições surgem em duas áreas-chave: (1) âncoras de confiança, e (2) nomes DNS.

Os navegadores modernos (como o warez que estamos a usar em 2014/2015) querem um certificado que acorrente a uma âncora de confiança, e querem que os nomes do DNS sejam apresentados de formas particulares no certificado. E os navegadores estão a mover-se activamente contra os certificados dos servidores autossignados

Alguns navegadores não facilitam a importação de um certificado auto-assinado do servidor. Na verdade, você não pode com alguns navegadores, como o navegador Android. Então a solução completa é tornar-se sua própria autoridade. Na ausência de se tornar sua própria autoridade, você tem que obter os nomes do DNS para dar ao certificado A maior chance de sucesso. Mas encorajá-lo-ia a tornar-se a sua própria autoridade. É fácil tornar-se sua própria autoridade e vai acompanhar todas as questões de confiança (quem melhor para confiar do que e tu?).

---

Este não é provavelmente o site que você está procurando!
O certificado de segurança do site não é de confiança!

Isto acontece porque os navegadores usam uma lista predefinida de âncoras de confiança para validar os certificados do servidor. Um certificado autossignado não acorrenta a uma âncora de confiança.

A melhor maneira de evitar isto é:

1. cria a tua própria autoridade (I. E., torna-te uma CA)
2. criar um pedido de assinatura de certificado (RSE) para o servidor
Assina a RSE do servidor com a tua chave de AC.
3. Instale o certificado do servidor no servidor
4. Instale o certificado da AC no cliente

Passo 1 - criar a sua própria autoridade só significa criar um certificado autossignado com CA: true e a utilização adequada da chave. Isso significa que o sujeito e o emitente são a mesma entidade, AC é verdadeiro em restrições básicas( ele também deve ser marcado como crítico), uso de chave é keyCertSign e crlSign (Se você é usando CRLs), e o identificador de Chave assunto (SKI) é o mesmo que o identificador de chave da Autoridade (AKI).

Para se tornar a sua própria autoridade de certificação, veja Como é que assina o pedido de assinatura do certificado com a sua autoridade de Certificação?Na pilha a transbordar. Em seguida, importar o seu CA para a Loja de confiança usada pelo navegador.

Os passos 2-4 são mais ou menos o que se faz agora para um servidor público de frente quando se recrutam os Serviços de uma AC como Startcom ou CAcert. Passos 1 e 5 permite que você evite a Autoridade de terceiros, e agir como sua própria autoridade (quem melhor para confiar do que você mesmo?).

A melhor maneira de evitar o aviso do navegador é confiar no certificado do servidor. Mas alguns navegadores, como o navegador padrão do Android, não permitem que você faça isso. Por isso, nunca funcionará na plataforma.

A emissão de browsers (e outros agentes de utilizadores similares) Não a confiança nos certificados autossuídos vai ser um grande problema na Internet das Coisas (IoT). Por exemplo, o que vai acontecer quando você se conectar ao seu termóstato ou geladeira para programá-lo? A resposta é, nada de bom no que diz respeito à experiência do Usuário. O grupo de trabalho WebAppSec do W3C está a começar a analisar a questão. Veja, por exemplo, proposta: marcar HTTP como não Seguro.

---

Como criar um certificado autossignado com o openssl?

Os comandos abaixo e a configuração ficheiro criar um certificado auto-assinado (também mostra como criar um pedido de assinatura). Eles diferem de outras respostas em um aspecto: os nomes DNS utilizados para o certificado autossignado estão no nome alternativo sujeito (SAN), e não o nome comum (CN).

Os nomes do DNS são colocados no SAN através do ficheiro de configuração com a linha subjectAltName = @alternate_names (não há como fazê-lo através da linha de comandos). Depois há uma secção alternate_names no ficheiro de configuração (você deve afinar isto de acordo com o seu gosto.

[ 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

É importante colocar o nome DNS na SAN e não na CN porque tanto o IETF como os fóruns CA/Browser especificam a prática. Especificam igualmente que as denominações DNS na NC são depreciadas (mas não proibidas). se colocares um nome DNS na NC, então deve ser incluído na SAN sob as políticas da CA / B. Não podes evitar usar o nome alternativo.

Se não colocares nomes DNS no SAN, então o certificado não validará sob um navegador e outros agentes de usuário que seguem as diretrizes do Fórum CA/Browser.

Relacionado: os navegadores seguem as políticas do Fórum AC/Browser; e não as políticas do IETF. Essa é uma das razões pelas quais um certificado criado com o OpenSSL (que geralmente segue o IETF) às vezes não valida sob um navegador (navegadores seguem a AC/B). São normas diferentes, têm diferentes políticas de emissão e diferentes validações requisito.

---

Criar um certificado auto-assinado (repare na adição da opção -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

Crie um pedido de assinatura (repare na falta de -x509 opção):

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

Imprimir um certificado auto-assinado:

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

Imprimir um pedido de assinatura:

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

Ficheiro de configuração (passado através da opção -config )

[ 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 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
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
#   In either case, you probably only need serverAuth.
# 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
#   In either case, you probably only need serverAuth.
# 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

Pode ter de fazer o seguinte por cromado. Contrario O cromado pode queixar-se que um nome comum é inválido (ERR_CERT_COMMON_NAME_INVALID). Não sei qual é a relação entre um endereço IP na SAN e um CN neste caso.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

---

Existem outras regras relativas ao tratamento das denominações DNS nos certificados X. 509/PKIX. Consultar estes documentos para as regras:

• RFC 5280, Internet X. 509 Public Key Infrastructure Certificate and Certificate Revogation List (CRL) Profile
• RFC 6125, representação e verificação da identidade do serviço de aplicações baseado no domínio na infra-estrutura de Chave Pública da Internet utilizando certificados X. 509 (PKIX) no contexto da segurança dos níveis de transporte (TLS)
• RFC 6797, Apêndice A, HTTP Strict Transport Security (HSTS)
• RFC 7469, extensão de Remoção De Chaves Públicas para HTTP
• CA / Browser Forum Requisitos de base
• CA / Browser Forum validação alargada Directrizes

A RFC 6797 e a RFC 7469 são enumeradas porque são mais restritivas do que os outros RFCs e os documentos CA/B. Os RFC 6797 e 7469 também não permitem um endereço IP.

Aqui estão as opções descritas em @diegows ' s answer , descritas em mais detalhes, a partir de a documentação:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX

req

Pedido de certificado PKCS#10 e utilitário gerador de certificados.

-x509

Esta opção produz um certificado auto-assinado em vez de um pedido de certificado. Isto é tipicamente usado para gerar um certificado de teste ou uma AC raiz autossignada.

-newkey arg

Esta opção cria um novo pedido de certificado e uma nova chave privada. Argumento toma uma de várias formas. rsa: nbits , em que nbits é o número de bits, gera uma chave RSA nbits em tamanho.

-keyout filename

Isto dá o nome do ficheiro para onde escrever a chave privada recentemente criada.

-out filename

Isto indica o nome do ficheiro de saída a escrever ou o resultado padrão por omissão.

-days n

Quando se utiliza a opção -x509, indica-se o número de dias a certificar o certificado para. O padrão é 30 dias.

-nodes

Se esta opção for indicada, então se for criada uma chave privada, não será cifrada.

A documentação é mais detalhada do que a anterior, resumi-a aqui.

O seguinte comando serve todas as suas necessidades:

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650

Cria um certificado para o domínio {[1] } que é

• relativamente forte (a partir de 2018) e
• válido por 3650 dias (~10 anos).

Cria os seguintes ficheiros:

• chave privada: example.key
• Certificado: example.crt

Como toda a informação é fornecida na linha de comando, não há entrada interactiva irritante. Além disso, todos os passos necessários são executed by this single OpenSSL invocation: from private key generation up to the self-signed certificate.

Uma vez que o certificado é autossignificado e precisa de ser aceite pelos utilizadores manualmente, não faz sentido usar uma expiração curta ou uma cifra fraca.

No futuro, você pode querer usar mais de 4096 bits para a chave RSA e um algoritmo de hash mais forte que sha256, mas a partir de 2018 estes são valores sãos. Eles são suficientemente fortes, sendo apoiados por todos os modernos navegador.

Observação:, Teoricamente, você poderia deixar de fora o -nodes parâmetro (que significa "sem criptografia DES"), caso em que example.key seria criptografado com uma senha. No entanto, isso quase nunca é útil para uma instalação de servidor, porque você teria que armazenar a senha no servidor também, ou você teria que introduzi-la manualmente em cada reinicialização.

Não posso comentar, por isso vou colocar isto como uma resposta separada. Encontrei alguns problemas com a resposta aceite de uma linha:

• a linha única inclui uma frase-senha na chave.
• o único encarte usa o SHA1 que em muitos navegadores lança avisos na consola.

Aqui está uma versão simplificada que remove a frase-senha, aumenta a segurança para suprimir os avisos e inclui uma sugestão nos comentários para passar em-subj para remover a pergunta completa lista:

openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

Substitua 'localhost' por qualquer domínio que necessite. Terá de executar os dois primeiros comandos um a um, dado que o openssl irá pedir uma frase-senha.

Para combinar os dois em A.ficheiro pem:

cat server.crt server.key > cert.pem

Eu recomendaria adicionar o parâmetro - sha256 , para usar o algoritmo de hash SHA - 2, porque os navegadores principais estão a considerar mostrar "certificados SHA-1" Como não seguros.

A mesma linha de comandos da resposta aceite - @diegows com adição-sha256

Openssl req-x509 - sha256 - newkey rsa: 2048-keyout keyout.cert.pem-days XXX

Mais informações no Google Security blog .

Atualização De Maio De 2018. os comentários de que o uso do SHA-2 não adiciona qualquer segurança ao certificado autossignado. Mas eu ainda recomendo usá-lo como um bom hábito de não usar funções de hash criptográficas desatualizadas / inseguras. A explicação completa está disponível em: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificates-above-the-end-entity-certificate-to-be-sha1-base

Navegadores modernos agora lançam um erro de segurança para certificados auto-assinados de outra forma bem formados, se eles estão faltando um SAN (nome alternativo assunto). o OpenSSL não oferece uma forma de linha de comandos para indicar isto, tantos tutoriais e bookmarks de desenvolvedores estão de repente desatualizados.

A forma mais rápida de voltar a correr é um ficheiro conf curto e independente:

1. Criar um ficheiro de configuração do OpenSSL (exemplo: req.cnf)

   [req]
   distinguished_name = req_distinguished_name
   x509_extensions = v3_req
   prompt = no
   [req_distinguished_name]
   C = US
   ST = VA
   L = SomeCity
   O = MyCompany
   OU = MyDivision
   CN = www.company.com
   [v3_req]
   keyUsage = critical, digitalSignature, keyAgreement
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_names
   [alt_names]
   DNS.1 = www.company.com
   DNS.2 = company.com
   DNS.3 = company.net
   

2. Crie o certificado que referencia este ficheiro de configuração

   openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
    -keyout cert.key -out cert.pem -config req.cnf -sha256
   

Exemplo de configuração de https://support.citrix.com/article/CTX135602

Este é o programa que uso em caixas locais para definir o SAN (subjectAltName) em certificados autossignados.

Este programa leva o nome do domínio (example.com) e gera o SAN para *.example.com e example.com no mesmo certificado. As secções abaixo são comentadas. Indique o programa (por exemplo generate-ssl.sh) e dê-lhe permissões executáveis. Os arquivos serão escritos no mesmo diretório que o script.

Chrome 58 an onward requer que SAN seja colocado em auto-assinado certificado.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster@$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

Este programa também escreve um ficheiro info para que possa inspeccionar o novo certificado e verificar se o SAN está correctamente definido.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

Se estiver a utilizar o Apache, então poderá referenciar o certificado acima no seu ficheiro de configuração como por exemplo:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

Lembre-se de reiniciar o seu servidor Apache (ou Nginx, ou IIS) para que o novo certificado faça efeito.

2017 One liner:

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650

Isto também funciona no Chrome 57, uma vez que fornece o SAN, sem ter outro ficheiro de configuração. Retirado de uma resposta aqui. Isto cria um único .ficheiro pem que contém tanto a chave privada como o certificado. Podes movê-los para se separarem .ficheiros pem, se necessário.

Tem o procedimento geral correcto. A sintaxe para o comando está abaixo.

openssl req -new -key {private key file} -out {output file}

No entanto, os avisos são apresentados porque o navegador não foi capaz de verificar a identificação, validando o certificado com uma autoridade de certificado conhecida (AC).

Como este é um certificado autossignado não há CA e você pode ignorar com segurança o aviso e prosseguir. Se você quiser obter uma certeza real que será reconhecível por qualquer um na internet pública, então o procedimento é abaixo.

1. gerar uma chave privada
2. Use essa chave privada para criar um ficheiro CSR
3. submeter a RSE a CA (Verisign ou outros, etc.)
4. Install received cert from CA on web server
5. adicionar outros certificados à cadeia de autenticação, dependendo do tipo cert

Tenho mais detalhes sobre isso em um post em https://bigthinkingapplied.com/secure-the-connection-installing-certificates-on-3-common-web-servers/

Um liner FTW. Gosto de simplificar. Por que não usar um comando que contenha todos os argumentos necessários? É assim que eu gosto - isto cria um certificado x509 e é a chave PEM:

openssl req -x509 \
 -nodes -days 365 -newkey rsa:4096 \
 -keyout self.key.pem \
 -out self-x509.crt \
 -subj "/C=US/ST=WA/L=Seattle/CN=example.com/[email protected]" 

Esse comando único contém todas as respostas que normalmente forneceria para os detalhes do certificado. Desta forma você pode definir os params e executar o comando, obter a sua saída - em seguida, ir para o café.

>> mais aqui

Gerar chaves

Estou a usar /etc/mysql para armazenamento de cert porque /etc/apparmor.d/usr.sbin.mysqld contém /etc/mysql/*.pem r.

sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Adicionar configuração

/etc/mysql/my.cnf

[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem

[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

Na minha configuração, o servidor ubuntu ligou-se a: /var/log/mysql/error.log

Notas de acompanhamento:

• SSL error: Unable to get certificate from '...'

  Ao Mysql poderá ser negado o acesso de leitura ao seu ficheiro cert se não estiver na configuração dos apparmors . Como mencionado nos passos anteriores, Salve todas as nossas certs como .pem ficheiros na pasta /etc/mysql/ que são aprovados por omissão pelo apparmor (ou modificar o seu apparmor/SELinux para permitir o acesso a onde quer que os tenha guardado.)

• SSL error: Unable to get private key

  A sua versão do servidor de mysql pode não suportar o formato por omissão rsa:2048.

  Secreto gerado {[17] } para plano rsa com:

  openssl rsa -in server-key.pem -out server-key.pem
  openssl rsa -in client-key.pem -out client-key.pem
  

• Verificar se o servidor local suporta ssl:

  mysql -u root -p
  mysql> show variables like "%ssl%"; 
  +---------------+----------------------------+
  | Variable_name | Value                      |
  +---------------+----------------------------+
  | have_openssl  | YES                        |
  | have_ssl      | YES                        |
  | ssl_ca        | /etc/mysql/ca-cert.pem     |
  | ssl_capath    |                            |
  | ssl_cert      | /etc/mysql/server-cert.pem |
  | ssl_cipher    |                            |
  | ssl_key       | /etc/mysql/server-key.pem  |
  +---------------+----------------------------+
  

• Verificar uma ligação a o db está encriptado com ssl:

  A verificar a ligação

  Quando estiver ligado à instância MySQL, poderá emitir a consulta:

  show status like 'Ssl_cipher'; 
  

  Se a sua ligação não estiver encriptada, o resultado ficará em branco:

  mysql> show status like 'Ssl_cipher'; 
  +---------------+-------+ 
  | Variable_name | Value | 
  +---------------+-------+ 
  | Ssl_cipher    |       |  
  +---------------+-------+ 
  1 row in set (0.00 sec) 
  

  Caso contrário, mostraria uma corda de comprimento não-zero para o cypher em uso:

  mysql> show status like 'Ssl_cipher'; 
  +---------------+--------------------+ 
  | Variable_name | Value              | 
  +---------------+--------------------+ 
  | Ssl_cipher    | DHE-RSA-AES256-SHA |  
  +---------------+--------------------+ 
  1 row in set (0.00 sec) 
  

• Necessita de ssl para a ligação específica do utilizador ('necessita de ssl'):

  • SSL

  Diz ao servidor para permitir apenas ligações encriptadas com SSL para a conta.

  GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
    REQUIRE SSL;
  

  Para se ligar, o cliente deverá indicar a opção --ssl-ca para autenticar o certificado do servidor e poderá indicar adicionalmente as opções --ssl-key e --ssl-cert. Se nem for indicada a opção --ssl-ca nem a opção --ssl-capath, o cliente não autentica o certificado do servidor.

---

Link alternativo: longo tutorial aqui http://www.madirish.net/214

Oneliner v2017:

Cêntimos:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Ubuntu:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))