Czy coś przeoczyłem? Czy jest to prawidłowy sposób budowania certyfikatu z własnym podpisem?

Its easy to create a self signed certificate. Wystarczy użyć komendy openssl req. Tworzenie takiego, który może być zużywany przez największą liczbę klientów, takich jak przeglądarki i narzędzia wiersza poleceń, może być trudne.

Nowoczesne przeglądarki (jak warez, którego używamy w 2014/2015) chcą certyfikatu, który łączy się z kotwicą zaufania i chcą, aby nazwy DNS były prezentowane w określony sposób w certyfikacie. I przeglądarki aktywnie poruszają się przeciwko własnoręcznie podpisanym certyfikatom serwera

Niektóre przeglądarki nie ułatwiają importowania certyfikat serwera z własnym podpisem. W rzeczywistości nie możesz w niektórych przeglądarkach, takich jak przeglądarka Androida. Więc kompletnym rozwiązaniem jest stać się własnym autorytetem.

W przypadku braku stania się własnym autorytetem, musisz uzyskać prawo do nazw DNS, aby dać certyfikat Największej szansy na sukces. Ale chciałbym zachęcić cię, abyś stał się swoim własnym autorytetem. Łatwo stać się własnym autorytetem i będzie to krok po kroku wszystkie kwestie zaufania (komu lepiej ufać niż siebie?).

To prawdopodobnie nie jest strona, której szukasz!
Certyfikat bezpieczeństwa witryny nie jest zaufany!

Dzieje się tak dlatego, że przeglądarki używają predefiniowanej listy kotwic zaufania do walidacji certyfikatów serwera. Samo podpisany certyfikat nie łączy się z zaufaną kotwicą.

Najlepszym sposobem, aby tego uniknąć jest:

W 2006 roku został wybrany do Izby Reprezentantów.]}
1. Utwórz żądanie podpisania certyfikatu (CSR) dla serwera
2. podpisz CSR serwera kluczem CA
3. Zainstaluj certyfikat serwera na serwerze
4. Zainstaluj certyfikat CA na kliencie

Krok 1 - Utwórz swój własny autorytet oznacza po prostu utworzenie własnoręcznie podpisanego certyfikatu z CA: true i odpowiednim użyciem klucza. Oznacza to, że podmiot i Emitent są tym samym podmiotem, CA jest ustawiony na true w podstawowych ograniczeniach( powinien być również oznaczony jako krytyczny), użycie klucza to keyCertSign i crlSign (jeśli korzystanie z Crl), a identyfikator klucza podmiotu (SKI) jest taki sam jak identyfikator klucza organu (AKI).

Aby zostać własnym organem certyfikującym, zobacz jak podpisać wniosek o podpisanie certyfikatu w swoim urzędzie certyfikującym? on Stack Overflow. Następnie zaimportuj urząd certyfikacji do sklepu zaufania używanego przez przeglądarkę.

Kroki 2 - 4 są mniej więcej tym, co robisz teraz dla serwera publicznego, gdy korzystasz z usług CA, takich jak Startcom lub CAcert . Kroki 1 i 5 pozwalają uniknąć autorytetu strony trzeciej i działać jako własny autorytet (komu lepiej zaufać niż sobie?).

Następnym najlepszym sposobem uniknięcia Ostrzeżenia przeglądarki jest zaufanie do certyfikatu serwera. Ale niektóre przeglądarki, takie jak domyślna przeglądarka Androida, nie pozwalają ci na to. Więc nigdy nie będzie działać na platformie.

Problem przeglądarek (i innych podobnych agentów użytkowników) a nie ufanie certyfikatom podpisanym przez siebie będzie dużym problemem w Internet Rzeczy (IoT). Na przykład, co się stanie, gdy podłączysz do termostatu lub lodówki, aby go zaprogramować? Odpowiedź brzmi: nic dobrego, jeśli chodzi o doświadczenie użytkownika.

Grupa Robocza WebAppSec W3C zaczyna patrzeć na problem. Zobacz, na przykład, Proposal: oznaczanie HTTP jako niezabezpieczone .

Jak utworzyć certyfikat z własnym podpisem za pomocą openssl?

Poniższe polecenia i konfiguracja Plik Utwórz certyfikat z własnym podpisem (pokazuje również, jak utworzyć żądanie podpisania). Różnią się one od innych odpowiedzi pod jednym względem: nazwy DNS używane dla certyfikatu z własnym podpisem są w Subject Alternate Name (SAN) , a nie Common Name (CN).

Nazwy DNS są umieszczane w SAN poprzez plik konfiguracyjny z linią subjectAltName = @alternate_names (nie ma sposobu, aby to zrobić za pomocą linii poleceń). Następnie w pliku konfiguracyjnym znajduje się sekcja alternate_names (ty powinno to dopasować do Twojego gustu):

[ 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

Its important to put DNS name in the SAN and not the CN because both the IETF and the Ca/Browser Forums specific the practice. Określają również, że nazwy DNS w CN są przestarzałe (ale nie zabronione). jeśli umieścisz nazwę DNS w CN, to musi zostać włączona do SAN W ramach polityki CA/B. Więc nie można uniknąć używania alternatywnej nazwy tematu.

Jeśli nie umieścisz nazw DNS w SAN, wtedy certyfikat nie zostanie zweryfikowany w przeglądarce i innych agentach użytkowników, które postępują zgodnie z wytycznymi CA/Browser Forum.

Powiązane: przeglądarki przestrzegają zasad Forum CA/Browser, a nie zasad IETF. Jest to jeden z powodów, dla których certyfikat utworzony za pomocą OpenSSL (który zazwyczaj jest zgodny z IETF) czasami nie sprawdza się w przeglądarce (przeglądarki postępują zgodnie z ca/B). Są to różne standardy, mają różne zasady wydawania i różne walidacje wymagania.

Utwórz certyfikat z własnym podpisem (zauważ dodanie opcji -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

Tworzenie żądania podpisania (zwróć uwagę na brak opcji -x509):

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

Wydrukuj certyfikat z własnym podpisem :

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

Wydrukuj żądanie podpisania :

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

Plik konfiguracyjny (przekazany przez opcję -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

W przypadku Chrome może być konieczne wykonanie następujących czynności. Inaczej Chrome może narzekać, że nazwa zwyczajowa jest nieprawidłowa (ERR_CERT_COMMON_NAME_INVALID). Nie jestem pewien, jaki jest związek między adresem IP w SAN I CN w tym przypadku.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Istnieją inne zasady dotyczące obsługi nazw DNS w certyfikatach X. 509 / PKIX. Zasady znajdują się w tych dokumentach:

W 2008 roku firma Microsoft ogłosiła, że jej celem jest stworzenie platformy, która umożliwiłaby użytkownikom korzystanie z usług hostingu.]}
• RFC 6125, [140]} reprezentacja i weryfikacja tożsamości usługi aplikacji opartej na domenie w infrastrukturze klucza publicznego Internetu przy użyciu certyfikatów X. 509 (PKIX) w kontekście TLS (Transport Layer Security){[25]]}
[[44]}RFC 6797, Dodatek A, HTTP Strict Transport Security (HSTS)
• RFC 7469, rozszerzenie przypinania klucza publicznego dla HTTP
• CA / Forum przeglądarki wymagania podstawowe
• CA / Forum przeglądarki Rozszerzona Walidacja Wytyczne

RFC 6797 i RFC 7469 są wymienione, ponieważ są bardziej restrykcyjne niż inne dokumenty RFC i CA/B. RFC 6797 i 7469 również nie zezwalają na adres IP.

Oto opcje opisane w @diegows ' s answer, opisane bardziej szczegółowo, z dokumentacji :

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

req

PKCS#10 żądanie certyfikatu i narzędzie generujące certyfikat.

-x509

Ta opcja wyświetla certyfikat z podpisem własnym zamiast żądania certyfikatu. Jest to zwykle używane do generowania certyfikatu testowego lub samo podpisanego Root CA.

-newkey arg

Ta opcja tworzy nowe żądanie certyfikatu i Nowy klucz prywatny. Argumentacja przyjmuje jedną z kilku form. rsa: nbits, gdzie nbits jest liczbą bitów, generuje klucz RSA nbits w rozmiarze.

-keyout filename

To daje nazwę pliku do zapisu nowo utworzonego klucza prywatnego.

-out filename

Określa domyślnie nazwę pliku wyjściowego do zapisu lub standardowe wyjście.

-days n

Gdy używana jest opcja - x509 określa ona liczbę dni na certyfikację na certyfikat dla. Domyślnie jest to 30 dni.

-nodes

Jeśli ta opcja jest podana, to jeśli klucz prywatny zostanie utworzony, nie będzie on szyfrowany.

Dokumentacja jest właściwie bardziej szczegółowa niż powyższa, właśnie ją podsumowałem tutaj.

Poniższe polecenie spełnia wszystkie twoje potrzeby:

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

Tworzy certyfikat dla domeny {[1] } czyli

• stosunkowo silny (stan na 2018) i
• ważny przez 3650 dni (~10 lat).

Tworzy następujące pliki:

• klucz prywatny: example.key
• świadectwo: example.crt

Ponieważ wszystkie informacje są dostarczane w wierszu poleceń, nie ma irytującego interaktywnego wejścia. Ponadto wszystkie niezbędne kroki są wykonywane przez to pojedyncze wywołanie OpenSSL: od generowania klucza prywatnego do certyfikatu z własnym podpisem.

Ponieważ certyfikat jest własnoręcznie podpisany i musi zostać zaakceptowany przez użytkowników ręcznie, nie ma sensu używać krótkiej wygaśnięcia lub słabej krypto.

W przyszłości możesz chcieć użyć więcej niż 4096 bitów dla klucza RSA i algorytmu hashowego silniejszego niż sha256, ale od 2018 są to wartości rozsądne. Są wystarczająco silne, a jednocześnie są wspierane przez wszystkie nowoczesne przeglądarki.

Uwaga: teoretycznie można pominąć parametr -nodes (co oznacza "brak szyfrowania DES"), w którym to przypadku example.key byłoby zaszyfrowane hasłem. Jednak prawie nigdy nie jest to przydatne w przypadku instalacji serwera, ponieważ albo będziesz musiał zapisać hasło na serwerze, albo będziesz musiał wprowadzić je ręcznie przy każdym ponownym uruchomieniu.

Nie mogę skomentować, więc postawię to jako osobną odpowiedź. Znalazłem kilka problemów z zaakceptowaną jednowierszową odpowiedzią:

• One-liner zawiera hasło w kluczu.
• one-liner używa SHA1, który w wielu przeglądarkach wyświetla ostrzeżenia w konsoli.

Oto uproszczona wersja, która usuwa hasło, zwiększa bezpieczeństwo, aby tłumić ostrzeżenia i zawiera sugestię w komentarzach, aby przekazać in-subj, aby usunąć pełne pytanie 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

Zastąp 'localhost' dowolną domeną, której potrzebujesz. Będziesz musiał uruchomić dwa pierwsze polecenia jeden po drugim, ponieważ openssl poprosi o hasło.

Aby połączyć te dwa w a .plik pem:

cat server.crt server.key > cert.pem

Zalecałbym dodanie parametru -sha256, aby użyć algorytmu haszującego SHA-2, ponieważ główne przeglądarki rozważają pokazanie "certyfikatów SHA-1" jako Nie bezpiecznych.

Ta sama linia poleceń z zaakceptowanej odpowiedzi- @ diegows z dodanym -sha256

OpenSSL req-x509-sha256 - newkey RSA:2048-klucz keyout.pem-out cert.pem-dni XXX

Więcej informacji w Blog bezpieczeństwa Google.

Aktualizacja Maj 2018. Jak wielu zauważyło w komentarze, że użycie SHA-2 nie dodaje żadnych zabezpieczeń do certyfikatu podpisanego samodzielnie. Ale nadal zalecam używanie go jako dobrego nawyku nieużywania przestarzałych / niepewnych kryptograficznych funkcji skrótu. Pełne wyjaśnienie jest dostępne w: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificates-above-the-end-entity-certificate-to-be-sha1-base

Nowoczesne przeglądarki wyświetlają teraz błąd bezpieczeństwa dla dobrze uformowanych certyfikatów z własnym podpisem, jeśli brakuje im SAN (nazwa alternatywna podmiotu). OpenSSL nie dostarcza sposobu wiersza poleceń, aby to określić, tak wiele samouczków i zakładek programistów nagle się zdezaktualizowało.

Najszybszym sposobem na ponowne uruchomienie jest krótki, samodzielny plik conf:

1. Utwórz plik konfiguracyjny OpenSSL (przykład: 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. Create the certyfikat odwołujący się do tego pliku konfiguracyjnego

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

Przykładowa konfiguracja z https://support.citrix.com/article/CTX135602

Jest to skrypt, którego używam na lokalnych polach, aby ustawić SAN (subjectAltName) w certyfikatach podpisanych samodzielnie.

Ten skrypt przyjmuje nazwę domeny (example.com) i generuje SAN dla *.example.com oraz example.com w tym samym certyfikacie. Poniższe sekcje są komentowane. Nazwij skrypt (np. generate-ssl.sh) i nadaj mu uprawnienia wykonywalne. Pliki zostaną zapisane w tym samym katalogu co skrypt.

Chrome 58 wymaga ustawienia SAN w podpisie własnym certyfikaty.

#!/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"

Ten skrypt zapisuje również plik informacji, dzięki czemu można sprawdzić nowy certyfikat i sprawdzić, czy SAN jest ustawiony poprawnie.

                ...
                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:
     ...

Jeśli używasz Apache ' a, możesz odwołać się do powyższego cert w swoim pliku konfiguracyjnym w następujący sposób:

<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>

Pamiętaj, aby ponownie uruchomić serwer Apache (lub Nginx lub IIS), aby nowy cert wszedł w życie.

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

Działa to również w Chrome 57, ponieważ zapewnia SAN, bez konieczności posiadania innego pliku konfiguracyjnego. Zaczerpnięte z odpowiedzi tutaj . To tworzy pojedynczy .plik pem zawierający zarówno klucz prywatny, jak i cert. Możesz je rozdzielić .pliki pem w razie potrzeby.

Masz prawidłową ogólną procedurę. Składnia polecenia znajduje się poniżej.

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

Jednak ostrzeżenia są wyświetlane, ponieważ przeglądarka nie była w stanie zweryfikować identyfikatora poprzez walidację certyfikatu w znanym urzędzie certyfikacji (CA).

Ponieważ jest to certyfikat podpisany samodzielnie, nie ma CA i możesz bezpiecznie zignorować ostrzeżenie i kontynuować. Jeśli chcesz uzyskać prawdziwy cert, który będzie rozpoznawalny przez każdego w publicznym Internecie, procedura jest poniżej.

1. Wygeneruj klucz prywatny
2. Użyj tego klucza prywatnego, aby utworzyć plik CSR
3. zgłoś CSR do CA (Verisign lub inne itp.)
4. zainstaluj odebrany cert z CA na serwerze WWW
5. Dodaj inne certy do łańcucha uwierzytelniania w zależności od typu cert

Mam więcej szczegółów na ten temat w poście na https://bigthinkingapplied.com/secure-the-connection-installing-certificates-on-3-common-web-servers/

One liner FTW. Lubię to prostować. Dlaczego nie użyć jednego polecenia, które zawiera wszystkie potrzebne argumenty? Tak to lubię-to tworzy certyfikat x509 i jest to klucz 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]" 

To pojedyncze polecenie zawiera wszystkie odpowiedzi, które normalnie można podać dla szczegółów certyfikatu. W ten sposób można ustawić params i uruchomić polecenie, uzyskać wyjście - następnie przejść do kawy.

>> więcej tutaj

Generuj klucze

Używam /etc/mysql do przechowywania cert, ponieważ /etc/apparmor.d/usr.sbin.mysqld zawiera /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;

Dodaj konfigurację

/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

W mojej konfiguracji, ubuntu server zalogowany do: /var/log/mysql/error.log

Uwagi dodatkowe:

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

  Mysql może nie mieć dostępu do odczytu do pliku cert, jeśli nie znajduje się on w konfiguracji apparmors. Jak wspomniano w poprzednich krokach^, Zapisz wszystkie nasze certy jako pliki .pem w katalogu /etc/mysql/, który jest domyślnie zatwierdzony przez apparmor (lub zmodyfikuj swój apparmor / SELinux, aby umożliwić dostęp do dowolnego miejsca, w którym je przechowujesz.)

• SSL error: Unable to get private key

  Twoja wersja serwera mysql może nie obsługiwać domyślnego formatu rsa:2048.

  Wygenerowano rsa:2048 na zwykły rsa z:

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

• Sprawdź, czy serwer lokalny obsługuje 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  |
  +---------------+----------------------------+
  

• Sprawdzanie połączenia z db jest szyfrowane ssl :

  Sprawdzanie połączenia

  Po zalogowaniu się do instancji MySQL, możesz wydać zapytanie:

  show status like 'Ssl_cipher'; 
  

  Jeśli połączenie nie jest szyfrowane, wynik będzie pusty:

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

  W Przeciwnym Razie pokazywałoby niezerową długość ciągu dla używanego cyfera:

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

• Aby uzyskać dostęp do danych, należy użyć protokołu ssl (ang. require ssl for specific user ' s connection).]}

  • SSL

  Mówi serwerowi, aby zezwalał tylko na szyfrowane połączenia SSL dla konta.

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

  Aby się połączyć, klient MUSI podać opcję --ssl-ca do uwierzytelnienia certyfikatu serwera i może dodatkowo podać opcje --ssl-key I --ssl-cert. Jeśli nie podano ani opcji --ssl-ca, ani opcji --ssl-capath, klient nie uwierzytelni certyfikatu serwera.

Alternatywny link: długi tutorial tutaj http://www.madirish.net/214

Oneliner v2017:

Centos:

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"))