înregistrare Logare
Puncte:0
avatar Server

Actualizare/reînnoire certificat de server Postgres SSL cu openssl

drapel ms
aufmschlauch

Am moștenit un server Postgres de companie cu clienți SSL. Sunt aproximativ 100 de utilizatori până acum.

Două probleme: My Ca Cert (root.crt) expiră anul viitor și pare să fie încă TlsV1.0. Deci o actualizare (reînnoire) este nevoie urgentă.

Ceea ce ar trebui să evit este să fac noi certificate de client pentru toți utilizatorii într-unul singur. Ar deveni un cosmar pentru mine :-)

Așa că am căutat o soluție în care certificatele vechi și noi vor funcționa, până când toate certificatele vechi vor expira. Îmi plac o mulțime de indicii (și pe Serverfault), dar nimic nu a funcționat până acum.

Ce am facut pana acum: Folosesc vechea cheie ca (rootCa.key) și am creat un nou root.crt) și am folosit vechea cheie de server (server.key) pentru a crea un nou server.crt. Am instalat lista de revocare (root.crl), root.crt, server.crt și server.key pe serverul meu de rezervă Postgres.

Mă pot conecta cu certificatul newUser.crt, dar nu cu cele vechi... așa cum mă așteptam.

Am căutat ca naiba pe web și am găsit un indiciu pentru a îmbina certificatele vechi și noi pe server. Așa că am combinat certificatele cu cat: cat oldRoot.crt >> root.crt și pentru celelalte fișiere. Lista de revocare nu a funcționat, așa că am comentat linia: #ssl_crl_file = în Postgres.conf. Se pare că Postgres funcționează și fără listă de revocare.

Rezultat: În funcție de certificatul care vine primul în server.crt, m-aș putea conecta cu certificate vechi sau noi, dar niciodată cu ambele. Pentru a-l testa, am folosit merged root.crt cu oldServer.cert și, de asemenea, cu newServer.cert. Ambele au lucrat cu noi sau vechi.

Asta înseamnă că un root.crt îmbinat funcționează bine, dar nu un server.crt îmbinat.

L-am verificat cu openssl și am îmbinat root.crt și a îmbinat server.crt: openssl verify -verbose -x509_strict -CAfile root.crt -CApath . old_cert.crt server.crt old_cert.crt: OK server.crt: OK

openssl verify -verbose -x509_strict -CAfile root.crt -CApath . new_cert.crt server.crt new_cert.crt: OK server.crt: OK

Se pare că openssl poate gestiona certificatele îmbinate, dar nu și Postgres.

Ai idee cum să rezolvi această problemă?

Orice indiciu este apreciat.

Cu respect Schlauchi

server: Ubuntu 2104, Postgres13 server de rezervă: Ubuntu 1604, Postgres13

95
0 + 0
Puncte:0
avatar Server
drapel ms
aufmschlauch

Răspunsul meu scurt la întrebarea mea este: Yabadabbadooh.... este posibil și funcționează pe sistemul meu de rezervă!

Nu m-a lăsat să dorm, așa că am început din nou de la zero: Mai întâi am verificat din nou certificatele vechi și noi pentru orice diferență, singura diferență a fost o ordine diferită în subiect, dar același conținut.

#1 Așa că am făcut un nou root.crt și server.crt cu vechiul rootCa.key și vechiul server.key cu ordinea subiectului identică. Acum rezultatul textului a fost identic (subiect, algoritm de semnătură...)

#2 Am creat un userCert nou cu root.crt.

#3 Am instalat certificatele în Postgres și am testat -> funcționează.

#4 de data asta am început cu noi certificate pe partea de sus.

cat root_old.crt >> root.crt
cat server_old.crt >> server.crt
cat server_old.key >> server.key

restart postgres ...... Și acum certificatele vechi și noi funcționează!

#5 Verificați invers copiați certificatele vechi peste cele îmbinate și apoi:

cat root_new.crt >> root.crt
cat server_new.crt >> server.crt
cat server_new.key >> server.key

reporniți postgres ...... și nu mai funcționează. Reveniți la pasul 4, totul a funcționat bine din nou.

#6 Lista de revocare: am creat o listă de revocare pentru noile certificate și am instalat-o în postgres. atunci:

cat root_old.crl >> root.crl

a decomentat linia: ssl_crl_file = /root.crl repornire postgres ......Și totul funcționează bine.

Nu am idee de ce funcționează acum, nu-mi vine să cred că este ordinea subiectului... cred că am greșit altceva în primele încercări. Dar nu voi încerca să aflu, funcționează și asta este :-)

Concluzie:

Faceți root.crt (CA) și server.crt cu chei vechi și cât mai identice posibil. (verificați subiectul și așa)

Îmbinați certificatele, lista de revocare și cheia, astfel încât cele vechi să fie în partea de jos a fișierului

Acum certificatele vechi funcționează până când expiră și puteți crea certificate noi (cu CA nou) cu Tls actualizate, de exemplu.

Câteva informații suplimentare despre versiunea Tls. Când mi-am actualizat serverul la Ubuntu 2104 și Postgres 13, certificatele nu au funcționat. Am găsit indiciu pentru a adăuga această linie în /etc/ssl/openssl.conf

MinProtocol = TLSv1.0

Știu că acest lucru nu este bun, dar a ajutat pentru moment. Nu am putut găsi o modalitate de a testa dacă certificatele sunt Tlsv1.0 sau mai mare. Singurul test dacă TlsV1.2 folosea pgsql (13) sau pgadmin4, ambele nu vor funcționa cu TlsV1.0

Deci, în fișierul meu de configurare pentru crearea certificatului, folosesc asta:

MinProtocol = TLSv1.2

psql (13) și pgadmin4 funcționează acum cu noile certificate. Când toate cele vechi au expirat, voi schimba din nou /etc/ssl/openssl.conf la acea valoare.

Upgrade-ul la următoarea versiune Tls și-a pierdut mizul :-)

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.