MJU Vlada RS SIGEN-CA Overitelj na MJU English

VPRAŠANJA O SPLETNIH DIGITALNIH POTRDILIH ZA STREŽNIKE

 

 

   

Vprašanje:  Na našem strežniku Apache želimo dovoliti dostop samo brskalnikom z določenimi vrednostmi v digitalnem potrdilu, natančneje v spremenljivki SSL_CLIENT_S_DN.  Pri preverjanju konfiguracije s skripto "printenv" pa v izpisu ne vidimo nobene od spremenljivk za SSL. Zakaj?

Odgovor:  Eden od vzrokov je lahko ta, da morate od verzije mod_ssl 2.4.9 navzgor eksplicitno zahtevati tvorjenje  spremenljivk SSL_* z uporabo parametra SSLOptions +StdEnvVars.

   

Vprašanje: Naš Apache strežnik naj bi dovoljeval različno kontrolirane povezave (z overjanjem klientov ali brez tega), podobno, kot navajate v  vaših navodilih. Pri tem pa bi želeli vedno uporabiti standardni port 443, ker nekateri požarni zidovi ne dopuščajo povezav po nestandardnih portih.  Ali je to možno doseči z navideznimi imeni strežnikov (ServerName v okviru VirtualHost) na isti IP številki?

Odgovor: Protokol SSLv3 tega ne omogoča, ker ne teče na aplikacijskem nivoju, ampak pod njim. Paketi http med klientom in strežnikom so zašifrirani in tako strežnik ne ve, s katerim navideznim strežnikom se je klient hotel povezati. V tem primeru potrebujemo za vsak navidezni strežnik drug  "socket" (= IP + port). Če naj bo port vedno isti, morate za vsak navidezni strežnik uporabiti drugo IP številko.

Najprej so skušali rešiti ta problem tako, da bi v http protokol vgradili možnost prehoda na TLS (Upgrading to TLS Within HTTP/1.1 -RFC2817). Najprej se vzpostavi http povezava med klientom in strežnikom z navideznim imenom, potem pa se začnejo paketi šifrirati. Te možnosti ne podpira skoraj noben strežnik (izjema je apache od verzije 2.1) in noben od pogosteje uporabljanih brskalnikov.

V bodočo verzijo protokola TLSv1.1 ( RFC 4346 ) je vključena možnost razširitev TLS, kot so naštete v RFC 3546. Ena od njih je razširitev TLS z oznako imena strežnika (server name indication - SNI extension for TLS). Klient v handshake postopku poleg IP številke in porta pošlje strežniku še ime navideznega strežnika. Tako je povezava zašifrirana od vsega začetka, strežnik pa ve, s katerim od njegovih navideznih strežnikov se je klient hotel povezati.
Ta rešitev je kot implementacija RFC 3546 postala aktualna leta 2007, ker jo podpirajo brskalniki Firefox 2, Opera 7.6+ in MS Internet Explorer 7 na Windows Vista. Apache jo podpira od verzije 2.0, če ima vključen modul mod_gnutls, bo pa vključena v mod_ssl 0.9.9, ko bo na voljo ( navodila za instalacijo mod_gnutls)
Če boste torej uporabili to možnost, ste izključili vse uporabnike, ki imajo starejše brskalnike, zato velja z njeno uporabo še malo počakati.

Obenem naj opozorimo še na problem, ki se je pojavil z Windows Visto. Internet Exlorer 7 strežniku pošlje TLSv1 paket z razširitvami. Če ta ne podpira tega, bi se morala dogovoriti za vzpostavitev povezave brez razširitev (tako deluje n.pr. povezava z https://appl.sigen-ca.si). Opazili pa smo, da za nekatere aplikacije to ne velja in se povezava z njimi po protokolu TLSv1 ne vzpostavi. V takih primerih je smiselno v Internet Explorerju izključiti protokol TLSv1 (Orodja-> Internetne možnosti -> Napredno), tako da ostane samo možnost povezave prek SSLv3.

   

Vprašanje: Naš strežnik naj bi preverjal, ali je digitalno potrdilo odjemalca preklicano. Kje dobimo sezname preklicanih digitalnih potrdil SIGOV-CA in SIGEN-CA? Kako pogosto se obnavljajo?

Odgovor: SIGOV-CA in SIGEN-CA objavljata seznama preklicanih potrdil na spletnih naslovih in v imeniku X.500. Oba naslova sta vpisana v digitalno potrdilo v polju "Crl distribution points":

za SIGOV-CA:
   ldap://x500.gov.si/ou=sigov-ca,o=state-institutions,c=si?certificateRevocationList?base
   http://www.sigov-ca.gov.si/crl/sigov-ca.crl
za SIGEN-CA:
   ldap://x500.gov.si/ou=sigen-ca,o=state-institutions,c=si?certificateRevocationList?base
   http://www.sigen-ca.si/crl/sigen-ca.crl

S spleta ju lahko potegnete z naslovov:

SIGOV-CA:v obliki DER:http://www.sigov-ca.gov.si/crl/sigov-ca.crl, v obliki PEM:http://www.sigov-ca.gov.si/crl/sigov-ca.pem
SIGEN-CA:v obliki DER:http://www.sigen-ca.si/crl/sigen-ca.crl, v obliki PEM:http://www.sigen-ca.si/crl/sigen-ca.pem

Nalaganje iz imenika X.500:
ime strežnika: x500.gov.si, dostop po običajnih vratih za LDAP 389

Obnavljata se vsaj enkrat dnevno. Predvideni čas naslednje izdaje seznama vidimo v polju "Next Update" (v času po Greenwichu GMT, ki je eno uro za srednjeevropskim časom, poleti pa dve uri) in največ do tega časa velja tekoči seznam. Lahko pa pride do preklicev potrdil in objave novega seznama tudi prej. Problem nastane, če imamo naložen CRL, ki mu je čas veljavnosti potekel - večina strežnikov v takem primeru preneha vzpostavljati povezave.

Zaenkrat ima imenik x500.gov.si privzeto nastavitev, da vrača CRL v obliki ASCII, oziroma na zahtevo odjemalca tudi v binarni obliki. V začetku junija 2004 bomo to spremenili tako, da bo imenik vračal potrdila samo še v binarni obliki, kot je določeno za protokol LDAPv3.

    Strežnik Apache(z mod_ssl): zaenkrat ne podpira iskanja CRL po protokolu LDAP, zato mora vzdrževalec sam poskrbeti za osveževanje CRL. CRL v pem obliki najlaže snamemo s spletnega strežnika prek http, n.pr. z uporabo programa WGET. Če se odločimo za osveževanje CRL iz imenika x500.gov.si, moramo pripraviti posebno skripto, n.pr. v Perlu z uporabo modula LDAP.

Strežnik MS IIS poišče CRL po naslovih "CRL distribution points" v digitalnem potrdilu in sicer v binarni obliki. Če ne dobi ustreznega odgovora od imenika x500.gov.si, potegne CRL s spletnega strežnika.

   

Vprašanje: Pri pošiljanju zahtevka za potrdilo za strežnik sem dobil odgovor: "(-2731) PKIX : invalid request data. This might be caused by erroneous date, time or time zone settings.". Kaj je bilo narobe?

Odgovor: Verjetno to, da pri pripravi zahtevka za potrdilo v polje CN (Common Name) niste vpisali referenčne številke, ki ste jo dobili od SIGEN-CA. Ko SIGEN-CA tvori potrdilo za strežnik, se referenčna številka iz zahtevka zamenja z imenom strežnika.
Tvorite nov zahtevek za potrdilo in pri tem pazite, da bo v polju CN referenčna številka (8-mestno število).

Druga možnost pa je, da pri pripravi zahtevka za potrdilo niste vnesli imena organizacije in ste pustili to polje prazno.
Tvorite nov zahtevek za potrdilo in pri tem pazite, da bo v polju "Common Name" referenčna številka, v polju "Organization" pa ime organizacije.


   

Vprašanje: Pri pošiljanju zahtevka za potrdilo za strežnik sem dobil odgovor: "(-2753) PKIX : request missing". Kaj je bilo narobe?

Odgovor:  Verjetno to, da v zahtevku kateri od navedenih podatkov nima vrednosti:
n.pr:C=SI, ST=, L=Ljubljana, O=Podjetje, OU=Centrala, CN=93999677
V tem primeru je naveden podatek ST, ki pa je brez vrednosti. Ta zahtevek bi bil v redu, če bi za podatek ST vnesli neko vrednost, lahko tudi presledek. Je vseeno, kaj vnesete, saj bodo v potrdilu tisti podatki, ki ste jih podali v formularju za zahtevek za strežniško potrdilo.


   

Vprašanje: Zanima me, ali je mogoče dobiti digitalno potrdilo za splošno ime strežnika v obliki *.domena.si?

Odgovor:  Nekateri overitelji res izdajajo taka potrdila (wildcard certificate), ki pa jih ne podpirajo vsi strežniki in brskalniki. SIGEN-CA zaenkrat ne izdaja takih potrdil.

Morebitna vprašanja pošljite na .

 

© Overitelj na Ministrstvu za javno upravo RS