înregistrare Logare
Puncte:1
T2PS avatar Server

Apache 2.4: Necesită certificat de client numai pentru metodele non-GET

drapel br
T2PS

Avem un serviciu intern care rulează pe HTTP cu o instanță Apache 2.4 (Debian Bullseye) pusă în față ca proxy pentru HTTPS. Apache și HTTPS sunt în funcțiune, dar o cerință suplimentară este pentru certificatele client -- în mod specific, cererile GET și HEAD pot decurge anonim, dar toate celelalte metode trebuie să prezinte un certificat client valid care să îndeplinească anumite condiții.

Software-ul pe care îl construim vizează IIS, așa că Apache este o cantitate necunoscută pentru noi (de atunci implementatorul original a plecat). Încercările noastre de a adapta configurația pe care am moștenit-o au porțiunea site-ului din configurație (omițând directivele căii fișierului certificat) ca:

SSLVerifyClient opțional
SSLVerifyDepth 10

ProxyPass /intern http://<IPintern>:/intern
ProxyPassReverse /internal http://<internalIP>:/internal
SSLOptions +StdEnvVars

<Locație /internă>
  Comanda refuzată, permiteți
  Permite de la toți

  <LimitExcept GET>
    SSLRequire ( %{SSL_CLIENT_S_DN_O} eq „(org)” și %{SSL_CLIENT_S_DN_OU} eq „(unitate)” și %{SSL_CLIENT_S_CN} eq „(nume)” )
  </LimitExcept>
</Locație>

Nu am încercat încă acest lucru cu un certificat de client de ex. POST pentru că un simplu GET to https://<proxy>/internal acum eșuează cu un mesaj 403 și errors.log:

AH02229: accesul la proxy:http://{internalIP}/internal a eșuat, motiv: expresia cerinței SSL nu a fost îndeplinită

La prima vedere, aceasta arată ca SSLRequire verificarea este aplicată și pentru GET, spre deosebire de <LimitExcept>.

Există o combinație de directive pe care le putem folosi pentru a obține comportamentul dorit? (În mod ideal, unul care se îndepărtează de ceea ce aparent acum este depreciat SSLRequire de asemenea.)

142
0 + 0
Puncte:1
avatar Server
drapel in
Lacek

Poți să folosești mod_ssl cu autorizare de bază pentru a permite numai cei care au prezentat un certificat valabil. Trebuie să modificați LimitExcept parte cam asta:

<LimitExcept GET>
    AuthType Basic
    AuthName "no-GET thingy"
    Require ssl-verify-client
</LimitExcept>

Puteți utiliza orice număr și combinație de Solicita declarații, așa că dacă doriți să verificați și proprietățile certificatului, puteți face ceva de genul acesta:

<LimitExcept GET>
    AuthType Basic
    AuthName "no-GET thingy"
    <RequireAll>
        Require ssl-verify-client
        Require expr "'${SSL_CLIENT_S_DN_O}' == 'org'"
        Require expr "'${SSL_CLIENT_S_DN_OUT}' == 'theOU'"
        Require expr "'${SSL_CLIENT_S_DN_CN}' != 'notThisUser'"
    </RequireAll>
</LimitExcept>
0 + 0
T2PS avatar
drapel br
T2PS
Acest lucru funcționează în ceea ce privește solicitarea unui certificat, există o modalitate de a include și verificările proprietăților certificatului?
0
Răspunde
drapel in
Lacek
Am adăugat un exemplu de verificare a proprietăților certificatului clientului.
1
Răspunde
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.