Autentifikācija ar e-id karti Tavā lapā
Atkal viens makten tehnisks ieraksts. Piedodiet tie, kas nesaprot.
Tā kā mūsu LVRTC un eParaksts ir beiguši nodarboties ar muļķībām un iOS aplikācija arī ir pieejama, parunāsim par to, kā autentificēt ID karšu lietotājus savā lapā. Piemēram, cert.laacz.lv (nē, es neko nesaglabāju - pat logos ne).
Godīgi sakot, ID karte pat nav pats svarīgākais šajā vienādojumā. Autentifikācijas sertifikāts var būt uz datora uzinstalēts - tam nevajag fizisku kartiņu. Taču, tā kā mēs vieglus ceļus nemeklējam, tad viens no priekšnosacījumiem ir panākt to, ka lapas apmeklētāja dators ir atbilstoši sagatavots. Tam gan viņi beidzot ir pacentušies uztaisīt apvienotu instalāciju, kura uzliks gan jaunāko eParakstītāju, gan starprprogrammatūru, gan arī pārlūku spraudņus. Tas viss tikai par nieka 230MB...
Ļaut lietotājam autentificēties ar ID karti nozīmē to pašu, ko ļaut lietotājam autentificēties ar savu autentifikācijai domāto sertifikātu. Mūs interesējošajā gadījumā šis sertifikāts atrodas čipkartē un nav pieejams fiziskai bakstīšanai. Rupji sakot, mēs čipkartei varam pateikt - lūdzu, nošifrē šito. Čipkarte teiks - ok, bet iedod PIN. Tā kā sertifikāts ir unikāls katram, mēs varam viennozīmīgi pierādīt, ka šeit autentificēties mēģina Maiga Rasa, bet tur parakstu uzlikusi ir Skaidrīte Bija.
SSL/TLS autentifikācija ir webservera kompetencē. Tas tāpēc, ka es-tev-uzticos-tu-man-uzticies saruna notiek pirms cilvēks nonāk līdz Tavai lapai. Apache šādu klienta autentifikāciju var sakonfigurēt arī uz apakšdirektoriju, kamēr nginx tikai uz virtuālo hostu. Tā kā konfigurācijas principā neatšķiras, tad es koncentrēšos uz to, kas man bija pa rokai - Apache.
Sākumā mums ir jāizdomā - kam tad mēs uzticamies. Piemēram, iemetot aci eParaksts repozitārijā, izvēlamies tos autentifikācijas sertifikātu izsniedzējus, kuri mums šķiet pieņemami. Tie visi ir jānogādā uz servera, daži būs jāpārkonvertē uz PEM (jo ir DER formātā), jāpvieno kopā un lieta cepurē.
Tā kā mani interesē autentificēt tikai ID karšu lietotājus, tad sertifikātus ņēmu tikai tos. Teorētiski šo var attiecināt uz jebkuru karti ar autentifikācijas sertifikātu tajā. Kaut igauņu ID, kaut leišu.
Patlaban nav pieejams apkopots CA fails, tādēļ nāksies vien pastrādāt ar rociņām. Novelkam visus (pagaidām 11) sertifikātus kaut kur pie sevis. Tālāk jau nokonvertējam visus no DER uz PEM (openssl x509 -inform der -in sertifikats.crt -out sertifikats.pem
) un apvienojam (cat *.pem >id.crt
). Diemžēl, dēļ diezgan dīvaini izveidotās lapas (Angular, agresīvas referer pārbaudes pat satura sadaļā), automatizēt sertifikātu saraksta iegūšanu man īsti neizdevās.
Pieņemot, ka Apache vai nginx ar SSL jau ir nokonfigurēts, viss, kas jādara, ir jāpievieno papildus rindiņas SSLVerifyClient require
un SSLVerifyDepth 3
(ar trīs vajadzētu pietikt).
Viss, restartējam serveri un priecājamies ;)
Laiku pa laikam sertifikāti tiek atsaukti. Tas attiecas gan uz CA sertifikātiemm, gan uz izsniegtajiem individuālajiem. Starp citu, nevajag piemirst, ka laiku pa laikam būs nepieciešams atjaunināt arī CA sertifikātu sarakstu.
Ir divi veidi, kā tikt vaļā no problēmas, kad kāds mēģina autentificēties ar vairs nederīgu sertifikātu. Pirmais ir CRL (Certificate revocation list), kas faktiski ir saraksti ar sertifikātu identifikatoriem, kuri ir atsaukti. Bet tas nav mūsu ceļš. Ja nu tomēr vēlies ieviest, jo daži CA atbalsta tikai to, tad būs regulāri jāatjauno CA sertifikātos redzamie CRL saraksti. Tālāk jau Apache direktīvas SSLCARevocationFile vai SSLCARevocationPath.
Mana komandrinda ir šāda:
openssl crl2pkcs7 -nocrl -certfile id.crt \
| openssl pkcs7 -print_certs -text -noout \
| grep crl$ \
| sort | uniq \
| sed -r 's/^\s+URI://g' \
| xargs -n 1 curl -O
Atliek pēc katras šādas operācijas restartēt webserveri (ne pašu dzelzi, doh), tiesa.
Pareicais ceļš gan ir OCSP (Online Certificate Status Protocol). Ja CA šo atsaukumu pārbaudes veidu atbalsta, tad pietiek ar divām direktīvām iekš Apache konfigurācijas. Viena virtuālajā hostā SSLUseStapling on
(norāda, ka mūs tas interesē) un otra servera konfigurācijā SSLStaplingCache shmcb:/tmp/stapling\_cache(128000)
(norāda, kur saglabāt sarakstus, lai nebūtu visu laiku jāprasa CA serveriem).
Kas attiecas uz dokumentu parakstīšanu pārlūkā, tur ir stipri lielāks un jautrāks dancis. Par to, iespējams citreiz. Vai arī nekad.
Krišs
2018. gada 10. janvārī, plkst. 08:52
Par OCSP vs CRL - ir dzirdēts (pats neesmu pārbaudījis, bet dzirdēts), ka daļa OCSP serveru faktiski iekšienē tāpat vien izmanto kešotu derīgo sertifikātu sarakstu, līdz ar to OCSP izmantošana ne vienmēr garantē to, ka atsaukts sertifikāts tajā pat mirklī arī parādīsies kā atsaukts un tu viņu tāpēc noraidīsi.
Krikulis
2018. gada 10. janvārī, plkst. 11:47
Servera pusē OCSP lielākā priekšrocība ir tas, ka nevajag cronjobu, kas atjauno CRL + restartē serveri.
blah
2018. gada 16. janvārī, plkst. 20:19
OCSP stapling ne pa tēmu. Klienta sertifikāta pārbaudei jāizmanto SSLOCSPEnable direktīva.
Liepājnieks
2018. gada 26. martā, plkst. 20:00
Šis jau liekas overkills, ja netirgo neko, tad par sarežģītu un maz cilvēku, kas to izmanto. Ja tirgo, tad par sarežģītu, jo lielai daļai ir paypal, bet, kam nav tas parasti ielogojas ar internetbanku.
crayon
2019. gada 11. novembrī, plkst. 15:42
Vai Apache konfigā nevajag norādīt SSLOCSPResponderCertificateFile? Man visu laiku bļauj par root certificate not trusted
laacz Autors
2019. gada 11. novembrī, plkst. 15:48
Manā gadījumā nevajadzēja.