Puncte:2

Mysql 8.0 cu Letsencrypt SSL pe Ubuntu 20.4

drapel ht

Am instalat un certificat SSL Letsencrypt pe serverul meu VPN Ubuntu 20.4 și funcționează. Acum, încerc să configurez mysql pe acest server pentru SSL. Am citit multe postări care tratează aceeași problemă și am petrecut multe ore să o rezolv, fără succes.

Aceștia sunt pașii pe care i-am făcut:

  • Am copiat fișierele cert.pem, chain.pem, fullchain.pem și privkey.pem în /var/lib/mysql. Acestea sunt aceleași fișiere pe care le-am folosit pentru configurarea SSL a mea domeniu.

  • Configurația în mysql nu a fost clară. Am încercat diferite combinații în [mysql] și [mysqld]. Cel la care mă așteptam să fie corect, nu a funcționat: ssl_ca=/var/lib/mysql/cert.pem,ssl_cert=/var/lib/mysql/chain.pem,ssl_key=/var/lib/mysql/privkey.pem

    Doar această configurație funcționează fără a arunca o eroare. Notă: fullchain.pem conține certificatele de la cert.pem și chain.pem. În /etc/mysql/mysql.conf.d:

    [mysqld]
    
    ssl_cert=/var/lib/mysql/fullchain.pem
    
    ssl_key=/var/lib/mysql/privkey.pem
    

Mă pot conecta la mysql local de pe serverul meu și când verific atributele ssl, primesc:

(Enumerez doar variabilele cu valori)

| Nume_variabilă | Valoare |
+-------------------------------------+---------- -------------------+
| have_openssl | DA |                       
| have_ssl | DA |
| performanță_schema_show_processlist | OFF |
| ssl_cert | /var/lib/mysql/fullchain.pem | |
| ssl_fips_mode | OFF |
| ssl_key | /var/lib/mysql/privkey.pem 

Când alerg mysql > \s, Eu iau:

mysql Versiunea 8.0.21 pentru Win64 pe x86_64 (MySQL Community Server - GPL)

ID conexiune: 66
Baza de date curentă:
Utilizator curent: someUser@someIP
SSL: Cifrul utilizat este TLS_AES_256_GCM_SHA384
Folosind delimitator: ;
Versiunea serverului: 8.0.26-0ubuntu0.20.04.3 (Ubuntu)
Versiunea protocolului: 10
Conexiune: maraxai.de ​​prin TCP/IP
Set de caractere server: utf8mb4
Setul de caractere Db: utf8mb4
Set de caractere client: cp850
Set de caractere conectat: cp850
Port TCP: 3306
Date binare ca: Hexazecimal

Când alerg $ openssl s_client -connect maraxai.de:3306 -servername maraxai.de, mă aștept să obțin același rezultat ca și cu $ openssl s_client -connect maraxai.de:443 -servername maraxai.de, adică lanțul complet de certificate cu strângerea de mână reușită, dar, în schimb, primesc:

139990121219392:error:1408F10B:Rutine SSL:ssl3_get_record:număr de versiune greșit:../ssl/record/ssl3_record.c:331:
---
nu este disponibil niciun certificat de egalitate
---
Nu s-au trimis nume de CA de certificat de client
---
SSL handshake a citit 5 octeți și a scris 302 octeți
Verificare: OK
---
Nou, (NONE), Cipher este (NIMIC)
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Datele timpurii nu au fost trimise
Verificați codul de returnare: 0 (ok)

Unele postări sugerau că linia SSL handshake a citit 5 octeți și a scris 302 octeți sugerează că strângerea de mână SSL a fost pornită, dar a renunțat, deoarece serverul returnează ceva ce nu este așteptat.

Pentru a verifica în continuare, folosesc openssl s_client -connect maraxai.de:3306 -servername maraxai.de ​​-starttls mysql. Prima secțiune îmi spune despre error:num=20:nu se poate obține certificatul de emitent local și error:num=21:certificatul serverului nu este verificat pentru certificatul de server (adâncime: 0). În plus, văd un singur certificat (cert.pem). Certificatele intermediare ale chain.pem nu sunt listate. Acest lucru este ciudat, deoarece folosesc fullchain.pem, care este o concatenare a certificatelor din chain.pem și cert.pem.

CONECTAT(00000003)
adâncime=0 CN = maraxai.de
verify error:num=20:nu se poate obține certificatul de emitent local
verifica returnarea:1
adâncime=0 CN = maraxai.de
verify error:num=21:nu se poate verifica primul certificat
verifica returnarea:1
---
Lanț de certificate
 0 s:CN = maraxai.de
   i:C = US, O = Let's Encrypt, CN = R3
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----
//MIIF...
-----CERTIFICAT FINAL-----
subiect=CN = maraxai.de

emitent=C = SUA, O = Let's Encrypt, CN = R3

---
Nu s-au trimis nume de CA de certificat de client
Algoritmi de semnătură solicitați: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-25519:+RSA-PSS-PSS4 RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Algoritmi de semnătură solicitați partajați: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512+SHA512:RSHAS4-SHA25:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512+SHA512:RSHAS44 :RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Rezumat peer signing: SHA256
Tip semnătură peer: RSA-PSS
Cheie Temp Server: X25519, 253 de biți
---
SSL handshake a citit 2027 de octeți și a scris 448 de octeți
Eroare de verificare: nu se poate verifica primul certificat
---
Nou, TLSv1.3, Cipher este TLS_AES_256_GCM_SHA384
Cheia publică a serverului este de 2048 biți
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Datele timpurii nu au fost trimise
Verificați codul de returnare: 21 (nu se poate verifica primul certificat)
---
---
A sosit noua sesiune după strângere de mână:
Sesiune SSL:
    Protocol: TLSv1.3
    Cifrare: TLS_AES_256_GCM_SHA384
    ID sesiune: B157BD91FF0A458D6A546C26CB5665C95CD88B99CE6C66A5D98783642C39EFA4
    ID-ul sesiunii-ctx:
    PSK de reluare: CB807FC16CE11EB47FE7BDDD99C71A5AAF1AE5CDC600A127230E914AFC4AE1018A34F72F44741D2440EB4917D5DDD0D7
    Identitate PSK: Niciuna
    Sugestie de identitate PSK: Niciuna
    Nume de utilizator SRP: niciunul
    Sugestie pentru durata de viață a biletului de sesiune TLS: 7200 (secunde)
    Tichet sesiune TLS:
    // ...0000 - 00e0


    Ora de începere: 1645286635
    Timeout: 7200 (sec)
    Verificați codul de returnare: 21 (nu se poate verifica primul certificat)
    Secret principal extins: nu
    Date maxime timpurii: 0
---
citeste R BLOC
2ââ#08S01Tiempul expirat pentru citirea pachetelor de comunicareread:errno=0

Pentru a verifica dacă emitenții și subiectele certificatelor sunt setate corect, rulez:

openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout

Totul pare ok aici:

subiect=CN = maraxai.de
emitent=C = SUA, O = Let's Encrypt, CN = R3

subiect=C = US, O = Let's Encrypt, CN = R3
emitent=C = SUA, O = Internet Security Research Group, CN = ISRG Root X1

subiect=C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
emitent=O = Digital Signature Trust Co., CN = DST Root CA X3

De asemenea, pentru privkey.pem, am schimbat formatul cheii la PKCS#1 pentru a obține antetul corect -----BEGIN RSA PRIVATE KEY----- cu comanda $ openssl rsa -in privkey.pem -out privkey.pem.

Nu am idee cum să investighez în continuare această problemă. Orice ajutor ar fi foarte apreciat.

drapel in
Certificatele SSL și portul 443 sunt în general aplicate Apache, nu MySQL. Ați configurat MySQL să asculte atât 3306, cât și 443? Scopul este ca mașinile externe să se conecteze la această bază de date prin SSL, mai degrabă decât printr-o metodă securizată mai comună, cum ar fi tunelul SSH?
drapel ht
Da, am nevoie de o conexiune externă. Vreau să rulez o aplicație Nodejs pe domeniul meu, un chestionar. Întrebările sunt stocate în MySQL, precum și răspunsurile. La finalizare, va fi generat un PDF care va fi trimis prin e-mail utilizatorului. Serverul ascultă pe portul 443 pentru Apache și pe portul 3306 pentru MySQL.
drapel ht
Trebuie să mă corectez: conexiunea externă mysql funcționează. Eu iau: SSL: Cifrul utilizat este TLS_AES_256_GCM_SHA384 Conexiune: maraxai.de ​​prin TCP/IP Port TCP: 3306

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.