Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
autor |
sõnum |
|
Renka
HV Guru
liitunud: 31.03.2002
|
17.12.2014 19:56:17
ID-kaart ja nginx |
|
|
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 |
|
|
henri17
HV kasutaja
liitunud: 01.10.2006
|
17.12.2014 20:03:11
|
|
|
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 |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
17.12.2014 20:09:08
|
|
|
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 |
|
|
gynterk
HV kasutaja
liitunud: 17.01.2004
|
17.12.2014 20:41:08
|
|
|
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
server {
listen 127.0.0.1:443;
server_name id.example.net;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:!RC4:+HIGH:+MEDIUM;
ssl_certificate /path/to/ssl/id.example.net.crt;
ssl_certificate_key /path/to/ssl/id.example.net.key;
ssl_client_certificate /path/to/ssl/id.crt;
ssl_prefer_server_ciphers on;
ssl_session_timeout 5m;
ssl_verify_client optional;
ssl_verify_depth 2;
root /path/to/id.example.net/;
location ^~ /auth.php {
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_CLIENT_S_DN $ssl_client_s_dn;
include fastcgi_params;
fastcgi_pass unix:/path/to/var/php-fpm.sock;
}
location ~ /\.ht {
deny all;
}
} |
|
|
Kommentaarid: 5 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
5 |
|
tagasi üles |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
17.12.2014 20:50:26
|
|
|
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 |
|
|
haha20
HV kasutaja
liitunud: 29.04.2003
|
30.04.2015 09:03:05
|
|
|
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 |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
30.04.2015 09:54:02
|
|
|
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
_________________ There is no place like 127.0.0.1 |
|
Kommentaarid: 71 loe/lisa |
Kasutajad arvavad: |
|
:: |
2 :: |
1 :: |
61 |
|
tagasi üles |
|
|
kynkakunn
HV vaatleja
liitunud: 09.10.2006
|
|
Kommentaarid: 1 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
1 |
|
tagasi üles |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
05.07.2017 15:22:52
|
|
|
Ä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:
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:
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 |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
05.07.2017 19:11:43
|
|
|
Ja tänu sellel ticketile sai ka asja tuumani jõutud. SK poolt väljastatud sertidega ei ole kõik korras
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 Maha visatud aeg/raha.
_________________ There is no place like 127.0.0.1 |
|
Kommentaarid: 71 loe/lisa |
Kasutajad arvavad: |
|
:: |
2 :: |
1 :: |
61 |
|
tagasi üles |
|
|
incx
HV kasutaja
liitunud: 10.11.2001
|
05.07.2017 19:43:44
|
|
|
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 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 |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
05.07.2017 20:03:50
|
|
|
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 |
|
|
incx
HV kasutaja
liitunud: 10.11.2001
|
05.07.2017 20:16:39
|
|
|
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 |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
05.07.2017 20:28:37
|
|
|
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 |
|
|
incx
HV kasutaja
liitunud: 10.11.2001
|
05.07.2017 20:51:00
|
|
|
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 |
|
|
Renka
HV Guru
liitunud: 31.03.2002
|
05.07.2017 22:12:20
|
|
|
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 |
|
|
julmu
HV kasutaja
liitunud: 20.12.2004
|
07.07.2017 19:23:37
|
|
|
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 |
|
|
K3ndu
HV Guru
liitunud: 25.10.2009
|
07.07.2017 19:59:43
|
|
|
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 |
|
|
incx
HV kasutaja
liitunud: 10.11.2001
|
07.07.2017 21:13:39
|
|
|
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 , 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 |
|
|
|