Avaleht
uus teema   vasta Tarkvara »  WWW »  ID-kaart ja nginx märgi kõik teemad loetuks
märgi mitteloetuks
vaata eelmist teemat :: vaata järgmist teemat
Hinnavaatlus :: Foorum :: Uudised :: Ärifoorumid :: HV F1 ennustusvõistlus :: Pangalink :: Telekavad :: HV toote otsing
autor
sõnum Saada viide sõbrale. Teata moderaatorile
otsing:  
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 17.12.2014 19:56:17 ID-kaart ja nginx vasta tsitaadiga

Heip,

ehk on kellelgi kogemusi ID-kaardi ja nginx kooslusega. Teoorias võiks minuarust selle tööle saada - pealiskaudsel uurimisel vähemalt tundus nii. Aga kahjuks ei suutnud mingit head infoallikat leida mis vähe täpsemalt juhendaks. Ei ole kahjuks ise ka nginx'iga väga sügavuti kokku puutunud.

Sai ka SK käest uuritud, et kas nginx kohta järsku mingisugust infot on aga sealt tuli vastus sellise sõnastusega nagu nad kuuleksid nginx'ist esimest korda. Igal juhul ei pidanud ei nemad ega nende arenduspartner mitte midagi nginx/ID'kaart koosluse kohta teadma.


Igatahes oleks igasugune info teretulnud. Ei tahaks usukuda, et IIS ja Apache on nüüd ainsad variandid.

_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
henri17
HV kasutaja
henri17

liitunud: 01.10.2006




sõnum 17.12.2014 20:03:11 vasta tsitaadiga

On tehtav aga mitte mugavalt. Nginx ei saa konfigureerida 'ssl_verify_client' headerit saatma URL põhiselt. Hetkel on variant uus server konfigureerida teise pordi peale ja kasutaja sinna suunata.
Kommentaarid: 21 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 21
tagasi üles
vaata kasutaja infot saada privaatsõnum
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 17.12.2014 20:09:08 vasta tsitaadiga

henri17 kirjutas:
On tehtav aga mitte mugavalt. Nginx ei saa konfigureerida 'ssl_verify_client' headerit saatma URL põhiselt. Hetkel on variant uus server konfigureerida teise pordi peale ja kasutaja sinna suunata.
Asuh. See on asi mida vältida tahaks. Muidu võib ju samahästi ka Apache eraldi pordile seadistada.
_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
gynterk
HV kasutaja

liitunud: 17.01.2004




sõnum 17.12.2014 20:41:08 vasta tsitaadiga

ID kaart + Nginx töötab kenasti. Kui kaugele oled hetkel enda asjadega jõudnud st kui võimalik võiksid mingit olemasolevat confi jagada? Isiklikult viiksin kogu kompoti eraldi alamdomeeni alla, nt nii:
Spoiler Spoiler Spoiler
Kommentaarid: 5 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 5
tagasi üles
vaata kasutaja infot saada privaatsõnum
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 17.12.2014 20:50:26 vasta tsitaadiga

gynterk, tänud - uurin seda lahendust mingi hetk.

Mingit olemasolevat lahendust ei olegi hetkel. Uurisin puhtteoreetiliselt alles ja pean plaani kuidas kogu asi arendatava lahenduse struktuuri mahuks. Järgmine nädal vast jõuan katsetamiseni alles - muud tööd enne käsil kahjuks.

_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
haha20
HV kasutaja

liitunud: 29.04.2003




sõnum 30.04.2015 09:03:05 vasta tsitaadiga

Tekkis ka endal huvi.
Renka kuidas ja kas sul õnnestus nginx peal tööle saada?
Kommentaarid: 2 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 2
tagasi üles
vaata kasutaja infot saada privaatsõnum
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 30.04.2015 09:54:02 vasta tsitaadiga

haha20, see asi läks päevakorrast maha vahepeal - aga teema on bookmarkitud ja peagi tuleb sellega tegelemine taas ette võtta. Annan siia ka teada siis kuidas õnnestus. gynterk pakutud lahendus muidu peale vaadates tundub olevat täitsa asja moodi mis võiks toimida igatahes icon_wink.gif
_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
kynkakunn
HV vaatleja

liitunud: 09.10.2006




sõnum 22.02.2016 11:42:31 nüüd on ametlik juhend täiesti olemas vasta tsitaadiga

http://www.id.ee/public/ID-kaardiga_autentimine_NGINX_serveril.pdf
Kommentaarid: 1 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 1
tagasi üles
vaata kasutaja infot saada privaatsõnum
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 15:22:52 vasta tsitaadiga

Ärataks selle teema ellu hea meelega.

Kaks muret on.

1. CRL kasutades saan veateate: "client SSL certificate verify error: (3:unable to get certificate CRL) while reading client request headers"
Veateade viitab nagu sellele, et nginx ei saa CRLi kätte. Samas on fail olemas. On olemas ka kõik vajalikud õigused (chmod 777 sai ka proovitud).
PS! ID autentimine ilma CRLita töötab kenasti. Probleem on just CRLi kasutamisel.

Üks asjalik nõuanne mida suutsin leida oli:
https://stackoverflow.com/questions/17086934/nginx-unable-to-get-certificate-crl kirjutas:
This occurs because nginx needs to have CRLs for every certificate that's mentioned in ssl_client_certificate cert chain, including the root CA's CRL.

Omaarust olen kõik vajaliku sellejaoks ka teinud kuid siiski ei midagi.

ssl_client_certificate sert koosneb mul siis sellistest sertifikaatidest:
EE Certification Centre Root CA https://sk.ee/upload/files/EE_Certification_Centre_Root_CA.pem.crt
EID-SK 2011 https://sk.ee/upload/files/ESTEID-SK_2011.pem.crt
ESTEID-SK 2011 https://sk.ee/upload/files/ESTEID-SK_2011.pem.crt
ESTEID-SK 2015 https://sk.ee/upload/files/ESTEID-SK_2015.pem.crt

ssl_crl koosneb siis vastavalt:
http://www.sk.ee/crls/eeccrca/eeccrca.crl
http://www.sk.ee/repository/crls/eid2011.crl
http://www.sk.ee/repository/crls/esteid2011.crl
http://www.sk.ee/crls/esteid/esteid2015.crl

Oleks nagu kõik ju õige? Või on midagi puudu

PS! kasutades käsurealt openssl'i siis CRLi vastu valideerimine kõik kenasti ka toimib. openssl käsurealt kasutades tuleb küll ca.crl faili mergeda kokku ka ssl_client_certificate sertifikaadid.
openssl verify -crl_check -CAfile ca.crl mycert.cer
mycert.cer on siis ID kaardi haldusvahenist salvestatud autentimise sertifikaat.



2. $ssl_client_cert ei õnnestu proxy_set_header'iga edastada.
Dokumentatsioonis on niimoodi kirjas:
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#var_ssl_client_cert kirjutas:
$ssl_client_cert
returns the client certificate in the PEM format for an established SSL connection, with each line except the first prepended with the tab character; this is intended for the use in the proxy_set_header directive;

Reaalsuses liigub proxy kaudu edasi ainult sertifikaadi esimene rida. Saan aru, et OCSP kasutamiseks oleks mul vaja tervet sertifikaati siiski rakendusse saada.



Kombineerides eelnevaid vastuseid ja netitarkust siis olen saanud kokku sellise konfiguratsiooni:

PS! Varasemates näidetes on proxy_set_header võtmeteks kasutatud alakriipsuga stringe. See ei tööta viimaste Nginx versioonidega - neid headereid lihtsalt vaikselt ignoreeritakse. Seega on mul kõik sidekriipsuga asendatud.
PPS! Olen kõike üleval kirjutatut testinud nii 1.11.7 kui 1.13.1 versioonidega. Täpselt samad tulemused

server {
    listen            443 ssl;
    listen       [::]:443 ssl;

    server_name id.auth.local;

    access_log            /var/log/nginx/p443id.access.log;
    error_log             /var/log/nginx/p443id.error.log debug;

   ssl on;

   ssl_dhparam               /etc/nginx/cert/dhparam.pem;
   ssl_certificate           /etc/nginx/cert/nginx-selfsigned.crt;
   ssl_certificate_key       /etc/nginx/cert/nginx-selfsigned.key;
   ssl_session_cache         shared:SSL:10m;
   ssl_session_timeout       5m;
   ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
   ssl_prefer_server_ciphers on;
   ssl_ciphers               EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;

    ssl_crl /etc/nginx/cert/crl/ca.crl;
    ssl_client_certificate /etc/nginx/cert/eid.crt;
    ssl_verify_client on;
    ssl_session_cache off;
    ssl_verify_depth 3;

    location / {

      expires -1;

      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_set_header        SSL-CLIENT-VERIFY $ssl_client_verify;
      #proxy_set_header        SSL-CLIENT-CERT $ssl_client_cert;
      proxy_set_header        SSL-CLIENT-S-DN $ssl_client_s_dn;
      proxy_set_header        SSL-CLIENT-V-START $ssl_client_v_start;
      proxy_set_header        SSL-CLIENT-V-END $ssl_client_v_end;
      proxy_set_header        SSL-CLIENT-I-DN $ssl_client_i_dn;

      # Fix the “It appears that your reverse proxy set up is broken" error.
      proxy_pass          http://localhost:8088;
      proxy_read_timeout  90;

      proxy_redirect      http://localhost:8088 $host;
    }
}



Tegin nginx trackerisse ka bugreporti selle kohta. Jätan referentsiks ka siia. Võibolla läheb kellelgi tulevikus vaja: https://trac.nginx.org/nginx/ticket/1310

_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 19:11:43 vasta tsitaadiga

Ja tänu sellel ticketile sai ka asja tuumani jõutud. SK poolt väljastatud sertidega ei ole kõik korras icon_neutral.gif icon_mad.gif

https://trac.nginx.org/nginx/ticket/1094#comment:6 kirjutas:

The root certificate, "EE Certification Centre Root CA", has a CRL available at ​http://www.sk.ee/repository/crls/eeccrca.crl. This CRL lists Issuing Distrubution Point extension as follows:
tsitaat:

X509v3 Issuing Distrubution Point: critical
Full Name:
URI:http://www.sk.ee/repository/crls/eeccrca.crl



But there are no CRL Distribution Points in the certificate itself. As a result, OpenSSL refuses to to use this CRL when it tries to verify more than just a leaf certificate, for example:
tsitaat:

$ openssl verify -CAfile EE_Certification_Centre_Root_CA.pem.crt -CRLfile eeccrca.crl.pem -crl_check_all KLASS3-SK_2010_EECCRCA_SHA384.pem.crt
KLASS3-SK_2010_EECCRCA_SHA384.pem.crt: C = EE, O = AS Sertifitseerimiskeskus, CN = EE Certification Centre Root CA, emailAddress = pki@sk.ee
error 44 at 1 depth lookup:Different CRL scope

This probably should be reported to the sk.ee team, likely they want to fix this. Simply removing the IDP extension from the CRL should do the trick.


Ja ka sealsamas välja toodud SK vastus:
tsitaat:
Tere,

täname, et juhtisite sellele probleemile tähelepanu, aga oleme juba teadlikud,
et juursertifikaadis "EE Certification Centre Root CA" DP (Distribution Points)
atribuut puudu on. Võimalik ajutine lahendus ehk on IDP eemaldamine
tühistusnimekirja profiilist, aga hetkel ei tea milline on selle mõju,
peame seda testima.

Hetkel on sellepärast juhendis
http://www.id.ee/public/Configuring_Apache_web_server_to_support_ID.pdf
parameeter SSLCARevocationCheck väärtusega "leaf"
(https://httpd.apache.org/docs/2.4/mod/mod_ssl.html)

Mihkel T.
Integraator
SK ID Solutions AS



Kuramus nii sk.ee kui id.ee sai siin kahe tööpäevaga läbi kammitud ja lisaks hulganisti googeldatud ning Nginx miski IRC chatis muret lahatud. Aga lõpuks tuleb välja, et tegu on SK poolt ammu teada probleemiga mille nad on ise tekitanud kuid on teadlikult dokumenteerimata jätnud icon_neutral.gif Maha visatud aeg/raha.

_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
incx
HV kasutaja
incx

liitunud: 10.11.2001



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 19:43:44 vasta tsitaadiga

Renka kirjutas:
2. $ssl_client_cert ei õnnestu proxy_set_header'iga edastada.


Mis sul seal proxy taga on? RHEL/CentOS mingi lähikuude Apache turvapäts nt keeras selle multiline headerite vastuvõtmise häki kinni (ei vasta RFC-dele kui õieti mäletan ja mingi turvakala veel otsa), vaffa oli post-patch hommikul paralleelselt "raffas paanikas" režiimis mitmes süsteemis uurida why the eff idkaardi autent "lambist" ära suri.

Renka kirjutas:
1. CRL kasutades saan veateate: "client SSL certificate verify error: (3:unable to get certificate CRL) while reading client request headers"


Renka kirjutas:
Aga lõpuks tuleb välja, et tegu on SK poolt ammu teada probleemiga mille nad on ise tekitanud kuid on teadlikult dokumenteerimata jätnud icon_neutral.gif Maha visatud aeg/raha.


Seda, et SK sertifikaadid ja CRL-id pidevalt kalavad ja kammivad, ei tohiks küll uudiseks ega ootamatuseks teha. Sügavalt ka kahtlen, kas neil on mingit ärilist huvi asja korda teha, arvestades et OCSP eest küsitakse pappi. Vähemalt vist enam aegunud serte CRLis ei hoita selleks et need ikka topeltsuured ja ebamugavad oleks. Ise sai sama kala otsa aasta-poolteist tagasi komistatud, SK reaktsioon oli suhtkoht 0.

_________________
I have never understood the female capacity to avoid a direct answer to any question.
-- Spock, "This Side of Paradise", stardate 3417.3
Kommentaarid: 20 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 20
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 20:03:50 vasta tsitaadiga

incx kirjutas:
Renka kirjutas:
2. $ssl_client_cert ei õnnestu proxy_set_header'iga edastada.


Mis sul seal proxy taga on? RHEL/CentOS mingi lähikuude Apache turvapäts nt keeras selle multiline headerite vastuvõtmise häki kinni (ei vasta RFC-dele kui õieti mäletan ja mingi turvakala veel otsa), vaffa oli post-patch hommikul paralleelselt "raffas paanikas" režiimis mitmes süsteemis uurida why the eff idkaardi autent "lambist" ära suri.
Selle kohta leidsin Nginx trackerist ka vastuse. Pmst jah uued standarditele vastavad asjad eeldavad ilma reavahetusteta headereid.

Naljakas on muidugi see, et selle Proxy taga asub mul Nginx ise - mis siis omakorda fastcgi_pass'iga PHPle asja saadab. Ma pole nüüd uurinud kas see nginx ise siis vastab sellele RFC7230'le või PHPga suheldes läheb asi kaotsi.

Nginx trackeris vastav mure: https://trac.nginx.org/nginx/ticket/857
Kummaline on muidugi, et ametlikku lahendust ei tule asjale ...


Üks idee oleks ID autentimine Apache peale panna. Aga kas oleks mõeldav seda teha nii, et Nginx proxyb päringu Apachesse ja siis seal alles autentitakse? Ma natukene kahtlen selle võimalikkuses. Aga on ehk kellelgi kogemusi?

_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
incx
HV kasutaja
incx

liitunud: 10.11.2001



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 20:16:39 vasta tsitaadiga

Renka kirjutas:
Üks idee oleks ID autentimine Apache peale panna. Aga kas oleks mõeldav seda teha nii, et Nginx proxyb päringu Apachesse ja siis seal alles autentitakse? Ma natukene kahtlen selle võimalikkuses. Aga on ehk kellelgi kogemusi?

TCP proxy oleks teoreetiliselt võimalik, aga ilmselt mitte eesmärki täitev. Midagi targemat nginx tasemel oleks kokku võetav terminiga MITM, kui see üldse kuidagi töötaks (ei tohiks).

Hetkel tundub suht kaks mitte kõige meeldivamat varianti:
1. Ise koodi pätsida ja oma versioon kompileerida kas siis uue muutuja toega või olemasoleva serialiseerimist häkkides.
2. Kasutada ticketis viidatud überhäkk headeri ümber-regeximis-porri.

_________________
I have never understood the female capacity to avoid a direct answer to any question.
-- Spock, "This Side of Paradise", stardate 3417.3
Kommentaarid: 20 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 20
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 20:28:37 vasta tsitaadiga

Klient ei ole nõus OCSP eest raha välja käima, et iga autentimise pealt SK'le miskit maksta nii, et kui CRLi tööle ei saa siis kas loobume ID kaardiga autentimisest või leiutab mingi hetk viisi Apachet paralleelselt kõrval jooksutada ainult autentimise jaoks.

Kuramus see ID kaardindus on ideepoolest ju nii hea ja tore asi. Aga iga kord kui sellega kokku on vaja puutuda siis see mädaneb igast otsast.
Küll kasutaja poolelt - Win peal töötab ainult Chromega mul, Mac peal olen lihtsalt loobunud ID kaardi kasutamisest. Rääkimata muudest muredest mis haldusvahendiga on olnud.
Või siis arendaja poolelt - no esiteks ei ole siiani mõistlikku dokumentatsiooni arendaja jaoks. On hulk miski eri dokumente - mõni juhendi nimega, mõni uudisena, mõni üldse PDF kujul ning miski ZIP pakitud näidised (zip? päriselt või? halloo github vmt lahendus???) - aga kõik on kuidagi poolkõvad ja annavad ainult mingi suuna kätte. Ja nüüd siis tuleb välja, et sertide konfiga pole ka kõik korras. Võiks ju ometi enda poolt asjad korda teha ja/või vajadusel veebiserveri arendajatega ühendust võtta. Tegu on ühelt poolt meie riigile tähtsa teenusega ja teiselt poolt 35% turuosaga veebiserveriga. Ma pole vähemalt ise kursis, et keegi uusi arendusi Apache peal väga teeks - kõik liigub ikka Nginx peale. Või siis millegi muu.

_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
incx
HV kasutaja
incx

liitunud: 10.11.2001



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 20:51:00 vasta tsitaadiga

Kuigi üldjuhul ei ütle ma kunagi ära SK jamade ja halfassimise kohta mõne halva sõna poetamisest, siis siin tegelikult võib vähemalt ~15% süüst ka Nginx omapärade ja põhimõtete kaela lükata. SSLCARevocationCheck ekvivalendi patchi ei aktsepteerita "aga tee CA hierarhia korda hoopis", $ssl_client_cert "töötab nagu dokumenteeritud" ja pakutud patchid olulist reaktsiooni ei saa... embkumb workaroundiks mingil määral probleemist.

Reaalselt on jah kõige lihtsam kõrvale panna sessiooni loomisel autentimiseks apats vms analoog püsti ja pärast kasutaja tagasi suunata. Muidugi see tähendab, et kogu kasutajasess pole kaardiga kaetud ja kui kaart välja võetakse, töötab ikka edasi, aga olenevalt süsteemi iseloomust võib see täitsa kosher olla.

Eriti leet-haxxor variant oleks muidugi veel alternatiivheaderitest (DN, issueri info jms) välja arvutada, mis CRLi alla sert käib ja siis serial-i järgi kontrollida, kas on listitud.

_________________
I have never understood the female capacity to avoid a direct answer to any question.
-- Spock, "This Side of Paradise", stardate 3417.3
Kommentaarid: 20 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 20
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
Renka
HV Guru
Renka

liitunud: 31.03.2002



Autoriseeritud ID-kaardiga

sõnum 05.07.2017 22:12:20 vasta tsitaadiga

nginx kriitikaga samuti täitsa nõus. Aga ma arvan, et SK on positsioonil, et nginxi vajadusel tagant torkida antud muudatuste tegemisel.
_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
julmu
HV kasutaja
julmu

liitunud: 20.12.2004




sõnum 07.07.2017 19:23:37 vasta tsitaadiga

Renka kirjutas:
Klient ei ole nõus OCSP eest raha välja käima, et iga autentimise pealt SK'le miskit maksta nii, et kui CRLi tööle ei saa siis kas loobume ID kaardiga autentimisest või leiutab mingi hetk viisi Apachet paralleelselt kõrval jooksutada ainult autentimise jaoks.

SK rääkis oma eelmisel aastakonverentsil, et nad uute CA-de jaoks ei hakka enam üldse CRLi pakkuma, vaid pakuvad selle asemel piirangutega tasuta OCSP teenust neile, kes maksta ei taha.
Ma ise pole küll seda proovinud, aga põhimõtteliselt peaks see sobima:
https://www.sk.ee/upload/files/2_Lisateenuste%20portfelli%20uuendused_Liisa%20Lukin_AK2016.pdf
Kommentaarid: 7 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 7
tagasi üles
vaata kasutaja infot saada privaatsõnum
K3ndu
HV Guru
K3ndu

liitunud: 25.10.2009



Autoriseeritud ID-kaardiga

sõnum 07.07.2017 19:59:43 vasta tsitaadiga

Kolmas häkk oleks ka ilmselt see, et ei võta CRL listi kasutusele, ID-kaardi autent töötab ka ilma selleta edukalt.
Kommentaarid: 120 loe/lisa Kasutajad arvavad:  :: 0 :: 1 :: 110
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
incx
HV kasutaja
incx

liitunud: 10.11.2001



Autoriseeritud ID-kaardiga

sõnum 07.07.2017 21:13:39 vasta tsitaadiga

julmu kirjutas:
SK rääkis oma eelmisel aastakonverentsil, et nad uute CA-de jaoks ei hakka enam üldse CRLi pakkuma, vaid pakuvad selle asemel piirangutega tasuta OCSP teenust neile, kes maksta ei taha.
Ma ise pole küll seda proovinud, aga põhimõtteliselt peaks see sobima:
https://www.sk.ee/upload/files/2_Lisateenuste%20portfelli%20uuendused_Liisa%20Lukin_AK2016.pdf

Kirjelduse järgi tekib tunne, et jälle mingi topeltporr kodune häkk, mida ükski standardne lahendus ei toeta. 10a kogemuse pealt oma aega testimisele enam ei viitsi raisata kuna hetkel vahetu vajadus endal puudub icon_razz.gif, aga ei oleks mitte veerandgrammigi üllatunud kui:
1. viidatud magic OCSP "aia"-urlid ilmselt ei oleks sertides seest viidatud ja see tarkus peab hardcodetud olema
2. OCSP serdid oleks kuskil random puu harust välja antud mis ei vastaks RFC-dele ja see tarkus peab hardcodetud olema

Pm eesmärgi (serdi kehtivuse kontrolli) täidaks kui vastav custom kood teha aga kuna pole "äriteenus" siis maksimaalselt nerfitud ja destandardiseeritud ja FUDitud et kui kasutad, siis oled mõttetu 9-18 mees, keda nagunii ei toetata. Nginx puhul, kus arendajal on hetkel seisukoht "standard või laku panni", on ikka efekt 0.

_________________
I have never understood the female capacity to avoid a direct answer to any question.
-- Spock, "This Side of Paradise", stardate 3417.3
Kommentaarid: 20 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 20
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
näita postitusi alates eelmisest:   
uus teema   vasta Tarkvara »  WWW »  ID-kaart ja nginx
[vaata eelmist teemat] [vaata järgmist teemat]
 lisa lemmikuks
näita foorumit:  
 ignoreeri teemat 
sa ei või postitada uusi teemasid siia foorumisse
sa ei või vastata selle foorumi teemadele
sa ei või muuta oma postitusi selles foorumis
sa ei või kustutada oma postitusi selles foorumis
sa ei või vastata küsitlustele selles foorumis
sa ei saa lisada manuseid selles foorumis
sa võid manuseid alla laadida selles foorumis



Hinnavaatlus ei vastuta foorumis tehtud postituste eest.