Kā izveidot PEM sertifikātus
PEM sertifikāts nav atsevišķs “sertifikāta veids” tādā nozīmē kā DV vai OV, bet gan ļoti izplatīts faila formāts, kurā glabā sertifikātus, privātās atslēgas, sertifikātu pieprasījumus un pilnas ķēdes. Praktiski tas ir tekstveida formāts ar rindām, kas sākas ar BEGIN un END, piemēram, CERTIFICATE, PRIVATE KEY vai CERTIFICATE REQUEST. Tieši tāpēc PEM faili ir īpaši ērti Linux serveros, NGINX, Apache, HAProxy, dažādos API klientos un daudzos automatizācijas scenārijos. Ja administratoram ir jāpievieno HTTPS vietnei, jāizveido CSR sertifikācijas iestādei vai jākonvertē PFX fails uz formātu, ko saprot web serveris, ļoti bieži darbs beidzas tieši ar PEM.
Ikdienā ar PEM strādā gan mazas mājaslapas, gan nopietnas biznesa infrastruktūras. Piemēram, interneta veikalam vai uzņēmuma vietnei ar SSL sertifikātiem vajag korekti sakārtotu sertifikāta, starpsertifikātu un privātās atslēgas komplektu. Ja serviss tiek uzturēts uz hostinga, daļa procesu var būt automatizēta, bet uz virtuālā servera administrators parasti pats pārvalda failus, atļaujas un OpenSSL komandas. Tāpēc izpratne par PEM nav tikai teorija, bet ikdienas administrēšanas prasme.
Vispirms jānošķir četri biežāk sastopamie elementi. Privātā atslēga ir slepens fails, kas paliek tikai pie jums un nedrīkst tikt publiskots. CSR jeb Certificate Signing Request ir pieprasījuma fails, kuru sūta sertifikācijas iestādei vai izmanto automatizētā izsniegšanā. CRT vai CERTIFICATE fails ir pats izsniegtais sertifikāts. Chain jeb starpsertifikātu ķēde ir papildu sertifikāti, kas palīdz klientiem uzticēties gala sertifikātam. Visi šie faili var eksistēt PEM formātā, un tieši tāpēc cilvēki nereti saka “izveidot PEM sertifikātu”, lai gan praksē viņi bieži domā visu komplektu, nevis tikai vienu failu.
Visdrošākā un visbiežākā darba secība ir šāda: vispirms izveido privāto atslēgu, tad izveido CSR, pēc tam saņem sertifikātu no izsniedzēja, pēc tam, ja nepieciešams, saliek kopā fullchain failu vai konvertē citus formātus uz PEM. Ja jūs šo secību saprotat, lielākā daļa ar sertifikātiem saistīto darbu kļūst loģiski. Sarežģījumi parasti sākas tad, kad tiek sajaukti faili, pazaudēta pareizā privātā atslēga vai aizmirsts, ka serverim vajag ne tikai gala sertifikātu, bet arī ķēdi.
# 1. Privātās atslēgas izveide openssl genrsa -out private.key 2048 # 2. CSR izveide openssl req -new -key private.key -out request.csr
Veidojot CSR, OpenSSL prasīs informāciju par valsti, organizāciju un Common Name. Tieši Common Name vai Subject Alternative Name dati nosaka, uz kādu domēnu sertifikāts būs derīgs. Ja serveris strādā ar example.com un www.example.com, šo daļu nevajag ievadīt pavirši. Praksē daudzi administratori jau sen izmanto SAN konfigurāciju, jo mūsdienu sertifikātu validācija balstās tieši uz Subject Alternative Name lauku, nevis tikai uz Common Name.
# CSR ar SAN konfigurācijas failu openssl req -new -key private.key -out request.csr -subj "/C=LV/ST=Riga/L=Riga/O=Company/CN=example.com"
Ja sertifikāts ir saņemts no sertifikācijas iestādes, rezultātā jums parasti ir viens vai vairāki faili: servera sertifikāts, intermediate chain un dažkārt arī root informācija. Linux vidē bieži veido fullchain failu, kurā servera sertifikāts ir pirmais, bet pēc tam seko starpsertifikāti. Tas ir svarīgi, jo bez pilnas ķēdes daļa klientu vai servisu var brīdināt par nepilnīgu uzticības ceļu. Ne vienmēr tas būs redzams uzreiz jūsu paša pārlūkā, jo lokālajā sistēmā kešs vai uzticības krātuve var problēmu noslēpt.
# Fullchain piemērs cat server.crt intermediate.crt > fullchain.pem
Ļoti izplatīts scenārijs ir PFX vai P12 faila konvertēšana uz PEM. Tas notiek, kad sertifikāts eksportēts no Windows servera, IIS vai cita produkta, bet pēc tam jāizmanto NGINX, Apache, HAProxy vai kādā API integrācijā. PFX satur gan sertifikātu, gan privāto atslēgu, dažkārt arī ķēdi, un ar OpenSSL to var sadalīt atsevišķos PEM failos. Šajā procesā svarīgi ir nesajaukt, kurš fails ir privātā atslēga un kurš ir sertifikāts, kā arī glabāt rezultātu drošā vietā ar korektām failu atļaujām.
# Sertifikāta iegūšana no PFX openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out server.crt # Privātās atslēgas iegūšana no PFX openssl pkcs12 -in certificate.pfx -nocerts -nodes -out private.key # Starpsertifikātu iegūšana openssl pkcs12 -in certificate.pfx -cacerts -nokeys -out chain.crt
PEM faili ir tekstveida, tāpēc tos var atvērt ar redaktoru un vizuāli pārbaudīt. Tas ir ērti, bet vienlaikus bīstami, ja administrators kļūdaini kopē saturu ar liekām atstarpēm, sabojā rindu pārnesumus vai saglabā privāto atslēgu nedrošā vietā. Privātajai atslēgai jābūt pieejamai tikai servisam vai administratoram, kam tā vajadzīga. Uz Linux parasti izmanto ierobežotas atļaujas, piemēram, 600 vai 640, un glabā failu direktorijā, kas nav publiski pieejama caur web serveri.
# Drošas atļaujas privātajai atslēgai chmod 600 private.key chown root:root private.key
Pēc izveides vai konvertēšanas ļoti ieteicams pārbaudīt, vai sertifikāts, atslēga un CSR tiešām atbilst viens otram. Klasiska kļūda ir mēģināt lietot sertifikātu ar nepareizo privāto atslēgu. Šādā situācijā NGINX vai Apache parasti atsakās startēt vai ziņo, ka private key neatbilst sertifikātam. Praktisks risinājums ir salīdzināt moduli vai fingerprint informāciju ar OpenSSL. Tas aizņem minūti, bet bieži ietaupa daudz laika diagnostikā.
# Pārbaude, vai atslēga atbilst sertifikātam openssl x509 -noout -modulus -in server.crt | openssl md5 openssl rsa -noout -modulus -in private.key | openssl md5 # CSR pārbaude openssl req -noout -text -in request.csr openssl x509 -noout -text -in server.crt
Vēl viens svarīgs scenārijs ir pašparakstīts sertifikāts. Tas ir noderīgs iekšējiem testiem, laboratorijai, izstrādes videi vai servisam, kas nav paredzēts publiskai uzticamai lietošanai. Tomēr pašparakstīts sertifikāts nav tas pats, kas publiski uzticams SSL sertifikāts vietnei klientiem. Ja lietotājs atver publisku lapu ar pašparakstītu sertifikātu, pārlūks rādīs brīdinājumu, jo sertifikātu nav parakstījusi uzticama sertifikācijas iestāde.
# Pašparakstīta sertifikāta izveide openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out server.crt
Pārbaude, izvietošana un biežākās kļūdas
Pēc PEM failu sagatavošanas nākamais solis ir to izvietošana serverī. Apache, NGINX un citi servisi izmanto atšķirīgu konfigurācijas sintaksi, taču loģika ir viena un tā pati: jānorāda sertifikāta fails un privātās atslēgas fails, bet daudzos gadījumos arī pilnā ķēde. Pēc konfigurācijas maiņas servisu nedrīkst akli pārstartēt produkcijā bez pārbaudes. Labāk vispirms izmantot konfigurācijas testu un tikai tad veikt reload vai restart, īpaši noslogotā vidē.
# NGINX konfigurācijas pārbaude nginx -t # Apache konfigurācijas pārbaude apachectl configtest
Biežākās kļūdas ir nepareiza failu secība fullchain failā, sajaukts sertifikāts ar ķēdi, nepareiza privātā atslēga, pārāk atvērtas failu atļaujas un sertifikāta izvietošana direktorijā, ko lasa citi lietotāji vai procesi. Vēl viena tipiska problēma ir aizmirsts atjaunošanas termiņš. Sertifikāts var būt tehniski korekts, bet, ja tā derīguma termiņš beidzas un nav monitoringa vai atjaunošanas procesa, rezultāts lietotājiem būs tas pats, kas pie bojāta SSL — pārlūka brīdinājumi un uzticības zudums.
Labākā prakse ir dokumentēt, no kurienes sertifikāts iegūts, kā saucas privātā atslēga, kur glabājas chain fails, kurš serviss tos izmanto un kad beidzas derīguma termiņš. Tas ir īpaši svarīgi, ja infrastruktūrā ir vairāki domēni vai vairāki administratori. PEM faili paši par sevi nav sarežģīti, bet kļūdas parasti rodas nevis OpenSSL sintakses dēļ, bet tāpēc, ka pēc laika neviens vairs neatceras, kurš fails kam bija paredzēts.
Ja šo procesu apgūst pareizi, PEM sertifikātu izveide un pārvaldība kļūst par rutīnas uzdevumu. Jūs zināt, kā izveidot atslēgu, kā sagatavot CSR, kā pieņemt un sakārtot izsniegto sertifikātu, kā veidot fullchain un kā pārbaudīt, vai viss atbilst viens otram. Tieši šī secīgā izpratne ļauj ne tikai “salabot SSL”, bet droši un pārskatāmi uzturēt HTTPS vidi ilgtermiņā.