ProHoster > Blog > Ma'muriyat > Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Maqola quyidagilar uchun foydali bo'ladi:

  • Client Cert nima ekanligini biladi va mobil Safari-da nima uchun veb-rozetkalar kerakligini tushunadi;
  • Men cheklangan odamlar doirasiga yoki faqat o'zimga veb-xizmatlarni nashr etmoqchiman;
  • hamma narsa allaqachon kimdir tomonidan qilingan deb o'ylaydi va dunyoni biroz qulayroq va xavfsizroq qilishni xohlaydi.

Websockets tarixi taxminan 8 yil oldin boshlangan. Ilgari usullar uzoq http so'rovlari (aslida javoblar) ko'rinishida ishlatilgan: foydalanuvchi brauzeri serverga so'rov yubordi va uning biror narsaga javob berishini kutdi, javobdan keyin u yana ulandi va kutdi. Ammo keyin veb-soketlar paydo bo'ldi.

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Bir necha yil oldin biz sof PHP-da o'z dasturimizni ishlab chiqdik, u https so'rovlaridan foydalana olmaydi, chunki bu havola qatlami. Yaqinda deyarli barcha veb-serverlar https orqali proksi-so'rovlarni yuborishni va ulanishni qo'llab-quvvatlashni o'rgandilar: yangilash.

Bu sodir bo'lganda, websockets SPA ilovalari uchun deyarli standart xizmatga aylandi, chunki server tashabbusi bilan foydalanuvchiga kontentni taqdim etish qanchalik qulay (boshqa foydalanuvchidan xabar yuborish yoki rasm, hujjat, taqdimotning yangi versiyasini yuklab olish). hozirda kimdir tahrir qilyapti).

Mijoz sertifikati ancha vaqtdan beri mavjud bo'lsa-da, u hali ham yaxshi qo'llab-quvvatlanmaydi, chunki uni chetlab o'tishga harakat qilganda juda ko'p muammolarni keltirib chiqaradi. Va (ehtimol :slightly_smiling_face: ) shuning uchun IOS brauzerlari (Safaridan tashqari) undan foydalanishni istamaydi va mahalliy sertifikatlar do'konidan talab qiladi. Sertifikatlar login/pass yoki ssh kalitlari yoki xavfsizlik devori orqali kerakli portlarni yopish bilan solishtirganda juda ko'p afzalliklarga ega. Lekin bu gap emas.

IOS-da sertifikatni o'rnatish tartibi juda oddiy (aniq ma'lumotlarsiz emas), lekin umuman olganda, u Internetda juda ko'p va faqat Safari brauzerida mavjud bo'lgan ko'rsatmalarga muvofiq amalga oshiriladi. Afsuski, Safari veb-rozetkalar uchun Client Cert-dan qanday foydalanishni bilmaydi, lekin Internetda bunday sertifikatni yaratish bo'yicha ko'plab ko'rsatmalar mavjud, ammo amalda bunga erishib bo'lmaydi.

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Veb-soketlarni tushunish uchun biz quyidagi rejadan foydalandik: muammo/gipoteza/yechim.

Muammo: IOS uchun Safari mobil brauzerida mijoz sertifikati bilan himoyalangan resurslarga so'rovlarni proksi-server qilishda veb-rozetkalarni qo'llab-quvvatlamaydi va sertifikatni qo'llab-quvvatlashni yoqqan boshqa ilovalar.

Gipotezalar:

  1. Ichki/tashqi proksi-resurslarning veb-rozetkalariga sertifikatlardan foydalanish uchun bunday istisnoni sozlash mumkin (hech qanday yo'qligini bilib).
  2. Veb-soketlar uchun oddiy (veb-soket bo'lmagan) brauzer so'rovi paytida yaratilgan vaqtinchalik seanslar yordamida noyob, xavfsiz va himoyalangan ulanishni amalga oshirishingiz mumkin.
  3. Vaqtinchalik seanslar bitta proksi-server yordamida amalga oshirilishi mumkin (faqat o'rnatilgan modullar va funksiyalar).
  4. Vaqtinchalik seans tokenlari allaqachon tayyor Apache modullari sifatida amalga oshirilgan.
  5. Vaqtinchalik seans tokenlari o'zaro ta'sir tuzilmasini mantiqiy loyihalash orqali amalga oshirilishi mumkin.

Amalga oshirilgandan keyin ko'rinadigan holat.

Ishning maqsadi: xizmatlar va infratuzilmani boshqarish qo'shimcha dasturlarsiz (masalan, VPN kabi) IOS tizimidagi mobil telefondan birlashtirilgan va xavfsiz bo'lishi kerak.

Qo'shimcha maqsad: mobil Internetda kontentni tezroq yetkazib berish bilan vaqt va resurslarni/telefon trafigini tejash (veb-rozetkasiz ba'zi xizmatlar keraksiz so'rovlarni keltirib chiqaradi).

Qanday tekshirish kerak?

1. Sahifalarni ochish: 

β€” Π½Π°ΠΏΡ€ΠΈΠΌΠ΅Ρ€, https://teamcity.yourdomain.com Π² мобильном Π±Ρ€Π°ΡƒΠ·Π΅Ρ€Π΅ Safari (доступСн Ρ‚Π°ΠΊΠΆΠ΅ Π² дСсктопной вСрсии) β€” Π²Ρ‹Π·Ρ‹Π²Π°Π΅Ρ‚ ΡƒΡΠΏΠ΅ΡˆΠ½ΠΎΠ΅ ΠΏΠΎΠ΄ΠΊΠ»ΡŽΡ‡Π΅Π½ΠΈΠ΅ ΠΊ Π²Π΅Π±-сокСтам.
β€” Π½Π°ΠΏΡ€ΠΈΠΌΠ΅Ρ€, https://teamcity.yourdomain.com/admin/admin.html?item=diagnostics&tab=webS…— ΠΏΠΎΠΊΠ°Π·Ρ‹Π²Π°Π΅Ρ‚ ping/pong.
β€” Π½Π°ΠΏΡ€ΠΈΠΌΠ΅Ρ€, https://rancher.yourdomain.com/p/c-84bnv:p-vkszd/workload/deployment:danidb:ph…-> viewlogs β€” ΠΏΠΎΠΊΠ°Π·Ρ‹Π²Π°Π΅Ρ‚ Π»ΠΎΠ³ΠΈ ΠΊΠΎΠ½Ρ‚Π΅ΠΉΠ½Π΅Ρ€Π°.

2. Yoki dasturchi konsolida:

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Gipotezani tekshirish:

1. Bunday istisnoni ichki/tashqi proksi-resurslarning veb-rozetkalariga sertifikatlardan foydalanish uchun sozlash mumkin (hech qanday bo'lmasligini bilib).

Bu erda 2 ta yechim topildi:

a) darajada 

<Location sock*> SSLVerifyClient optional </Location>
<Location /> SSLVerifyClient require </Location>

kirish darajasini o'zgartirish.

Ushbu usul quyidagi nuanslarga ega:

  • Sertifikatni tekshirish proksilangan resursga so'rov yuborilgandan so'ng, ya'ni so'rovni yuborishdan keyin amalga oshiriladi. Bu shuni anglatadiki, proksi-server avval yuklanadi va keyin himoyalangan xizmatga so'rovni o'chirib qo'yadi. Bu yomon, lekin tanqidiy emas;
  • http2 protokolida. U hali ham qoralamada va brauzer ishlab chiqaruvchilari buni qanday amalga oshirishni bilishmaydi #info about tls1.3 http2 post handshake (hozir ishlamayapti) RFC 8740 "HTTP/1.3 bilan TLS 2 dan foydalanish" ni amalga oshirish;
  • Ushbu qayta ishlashni qanday birlashtirish kerakligi aniq emas.

b) Asosiy darajada, sertifikatsiz ssl-ga ruxsat bering.

SSLVerifyClient talab qiladi => SSLVerifyClient ixtiyoriy, lekin bu proksi-serverning xavfsizlik darajasini pasaytiradi, chunki bunday ulanish sertifikatsiz qayta ishlanadi. Biroq, siz quyidagi ko'rsatma bilan proksi-serverlarga kirishni rad qilishingiz mumkin:

RewriteEngine        on
RewriteCond     %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteRule     .? - [F]
ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

Batafsil ma'lumotni ssl haqidagi maqolada topishingiz mumkin: Apache Server mijoz sertifikati autentifikatsiyasi

Ikkala variant ham sinovdan o'tkazildi, "b" varianti uning ko'p qirraliligi va http2 protokoli bilan mosligi uchun tanlangan.

Ushbu gipotezani tekshirishni yakunlash uchun konfiguratsiya bilan ko'plab tajribalar o'tkazildi, quyidagi dizaynlar sinovdan o'tkazildi:

agar = talab qilish = qayta yozish

Natijada quyidagi asosiy dizayn paydo bo'ladi:

SSLVerifyClient optional
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule     .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

#websocket for safari without cert auth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
...
    #Π·Π°ΠΌΠ΅Ρ‰Π°Π΅ΠΌ Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π²Π»Π°Π΄Π΅Π»ΡŒΡ†Ρƒ сСртификата Π½Π° Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π½ΠΎΠΌΠ΅Ρ€Ρƒ ΠΏΡ€ΠΎΡ‚ΠΎΠΊΠΎΠ»Π°
    SSLUserName SSl_PROTOCOL
</If>
</If>

Sertifikat egasi tomonidan mavjud ruxsatnomani hisobga olgan holda, ammo sertifikat etishmayotgan bo'lsa, men mavjud bo'lmagan sertifikat egasini SSl_PROTOCOL (SSL_CLIENT_S_DN_CN o'rniga) mavjud o'zgaruvchilardan biri shaklida qo'shishim kerak edi, hujjatlarda batafsil ma'lumot:

Apache moduli mod_ssl

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

2. Veb-soketlar uchun oddiy (veb-soket bo'lmagan) brauzer so'rovi vaqtida yaratilgan vaqtinchalik seanslar yordamida noyob, xavfsiz va himoyalangan ulanishni amalga oshirishingiz mumkin.

Oldingi tajribaga asoslanib, odatiy (veb-rozetkasi bo'lmagan) so'rov paytida veb-rozetka ulanishlari uchun vaqtinchalik tokenlarni tayyorlash uchun konfiguratsiyaga qo'shimcha bo'lim qo'shishingiz kerak.

#ΠΏΠΎΠ΄Π³ΠΎΡ‚ΠΎΠ²ΠΊΠ° ΠΏΠ΅Ρ€Π΅Π΄Π°Ρ‡Π° сСбС Π‘ookie Ρ‡Π΅Ρ€Π΅Π· ΠΏΠΎΠ»ΡŒΠ·ΠΎΠ²Π°Ρ‚Π΅Π»ΡŒΡΠΊΠΈΠΉ Π±Ρ€Π°ΡƒΠ·Π΅Ρ€
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
Header set Set-Cookie "websocket-allowed=true; path=/; Max-Age=100"
</If>
</If>

#ΠΏΡ€ΠΎΠ²Π΅Ρ€ΠΊΠ° Cookie для установлСния Π²Π΅Π±-сокСт соСдинСния
<source lang="javascript">
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
#check for exists cookie

#get and check
SetEnvIf Cookie "websocket-allowed=(.*)" env-var-name=$1

#or rewrite rule
RewriteCond %{HTTP_COOKIE} !^.*mycookie.*$

#or if
<If "%{HTTP_COOKIE} =~ /(^|; )cookie-names*=s*some-val(;|$)/ >
</If

</If>
</If>

Sinov shuni ko'rsatdiki, u ishlaydi. Cookie fayllarini foydalanuvchi brauzeri orqali o'zingizga o'tkazishingiz mumkin.

3. Vaqtinchalik seanslar bitta proksi-server (faqat o'rnatilgan modullar va funksiyalar) yordamida amalga oshirilishi mumkin.

Avval bilib olganimizdek, Apache shartli konstruksiyalarni yaratishga imkon beruvchi juda koβ€˜p asosiy funksiyalarga ega. Biroq, bizga ma'lumotlarimiz foydalanuvchi brauzerida bo'lganda himoya qilish uchun vositalar kerak, shuning uchun biz nimani va nima uchun saqlashni va qanday o'rnatilgan funktsiyalardan foydalanishimizni aniqlaymiz:

  • Bizga osonlikcha dekodlab bo'lmaydigan token kerak.
  • Bizga o'rnatilgan eskirgan token va serverda eskirganlikni tekshirish qobiliyatiga ega bo'lgan token kerak.
  • Bizga sertifikat egasi bilan bog'langan token kerak.

Bu xeshlash funksiyasi, tuz va tokenni eskirish sanasini talab qiladi. Hujjatlar asosida Apache HTTP serveridagi ifodalar bizda hammasi sha1 va %{TIME} mavjud.

Natijada ushbu dizayn paydo bo'ldi:

#Π½Π΅Ρ‚ сСртификата, ΠΈ ΠΎΠ±Ρ€Π°Ρ‰Π΅Π½ΠΈΠ΅ ΠΊ websocket
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
    SetEnvIf Cookie "zt-cert-sha1=([^;]+)" zt-cert-sha1=$1
    SetEnvIf Cookie "zt-cert-uid=([^;]+)" zt-cert-uid=$1
    SetEnvIf Cookie "zt-cert-date=([^;]+)" zt-cert-date=$1

#Ρ‚ΠΎΠ»ΡŒΠΊΠΎ Ρ‚Π°ΠΊ ΠΌΠΎΠΆΠ½ΠΎ Ρ€Π°Π±ΠΎΡ‚Π°Ρ‚ΡŒ с ΠΏΠ΅Ρ€Π΅ΠΌΠ΅Π½Π½Ρ‹ΠΌΠΈ, ΠΏΠΎΠ»ΡƒΡ‡Π΅Π½Π½Ρ‹ΠΌΠΈ Π² env-Π°Ρ… Π² этот ΠΌΠΎΠΌΠ΅Π½Ρ‚ Π²Ρ€Π΅ΠΌΠ΅Π½ΠΈ, Π±ΠΎΠ»Π΅Π΅ ΠΎΠ½ΠΈ Π½ΠΈΠ³Π΄Π΅ Π½Π΅ доступны для Ρ„ΡƒΠ½ΠΊΡ†ΠΈΠΈ Ρ…Π΅ΡˆΠΈΡ€ΠΎΠ²Π°Π½ΠΈΡ (ΠΏΠΎ ΠΎΡ‚Π΄Π΅Π»ΡŒΠ½ΠΎΡΡ‚ΠΈ ΠΌΠΎΠΆΠ½ΠΎ, Π½ΠΎ Π½Π΅ вмСстС, Π΄Π° ΠΈ Π΅Ρ‰Ρ‘ с Ρ…Π΅ΡˆΠΈΡ€ΠΎΠ²Π°Π½ΠΈΠ΅ΠΌ)
    <RequireAll>
        Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
        Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
    </RequireAll>
</If>
</If>

#Π΅ΡΡ‚ΡŒ сСртификат, Π·Π°ΠΏΡ€Π°ΡˆΠΈΠ²Π°Π΅Ρ‚ΡΡ Π½Π΅ websocket
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
    SetEnvIf Cookie "zt-cert-sha1=([^;]+)" HAVE_zt-cert-sha1=$1

    SetEnv zt_cert "path=/; HttpOnly;Secure;SameSite=Strict"
#НовыС ΠΊΡƒΠΊΠΈ ставятся, Ссли старых Π½Π΅Ρ‚
    Header add Set-Cookie "expr=zt-cert-sha1=%{sha1:salt1%{TIME}salt3%{SSL_CLIENT_S_DN_CN}salt2};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
    Header add Set-Cookie "expr=zt-cert-uid=%{SSL_CLIENT_S_DN_CN};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
    Header add Set-Cookie "expr=zt-cert-date=%{TIME};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
</If>
</If>

Maqsadga erishildi, lekin serverning eskirishi bilan bog'liq muammolar mavjud (siz bir yoshli Cookie-dan foydalanishingiz mumkin), ya'ni tokenlar ichki foydalanish uchun xavfsiz bo'lsa-da, sanoat (ommaviy) foydalanish uchun xavflidir.

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

4. Vaqtinchalik seans tokenlari allaqachon tayyor Apache modullari sifatida amalga oshirilgan.

Oldingi iteratsiyadan bitta muhim muammo qoldi - token qarishini nazorat qila olmaslik.

Biz buni amalga oshiradigan tayyor modulni qidirmoqdamiz: apache token json two factor auth

Ha, tayyor modullar bor, lekin ularning barchasi muayyan harakatlarga bog'langan va sessiya va qo'shimcha Cookie-fayllarni boshlash ko'rinishidagi artefaktlarga ega. Ya'ni, bir muncha vaqt emas.
Qidiruvga besh soat vaqt ketdi, bu esa aniq natija bermadi.

5. Vaqtinchalik seans tokenlari o'zaro aloqalar strukturasini mantiqiy loyihalash orqali amalga oshirilishi mumkin.

Tayyor modullar juda murakkab, chunki bizga faqat bir nechta funktsiyalar kerak.

Aytgancha, sana bilan bog'liq muammo shundaki, Apache-ning o'rnatilgan funktsiyalari kelajakdan sanani yaratishga imkon bermaydi va eskirganlikni tekshirishda o'rnatilgan funktsiyalarda matematik qo'shish/ayirish mavjud emas.

Ya'ni, siz yoza olmaysiz:

(%{env:zt-cert-date} + 30) > %{DATE}

Siz faqat ikkita raqamni solishtirishingiz mumkin.

Safari muammosini hal qilish yo'lini qidirib, men qiziqarli maqola topdim: HomeAssistant-ni mijoz sertifikatlari bilan himoyalash (Safari/iOS bilan ishlaydi)
U Nginx uchun Lua kodining namunasini tasvirlaydi va ma'lum bo'lishicha, biz allaqachon amalga oshirgan konfiguratsiya qismining mantig'ini juda takrorlaydi, xeshlash uchun hmac tuzlash usulidan foydalanish bundan mustasno ( bu Apache'da topilmadi).

Lua aniq mantiqqa ega til ekanligi ayon bo'ldi va Apache uchun oddiy narsa qilish mumkin:

Nginx va Apache o'rtasidagi farqni o'rganib chiqib:

Lua tili ishlab chiqaruvchisidan mavjud funksiyalar:
22.1 - Sana va vaqt

Biz hozirgi bilan solishtirish uchun kelajakdagi sanani belgilash uchun kichik Lua faylida env o'zgaruvchilarini o'rnatish yo'lini topdik.

Oddiy Lua skripti shunday ko'rinadi:

require 'apache2'

function handler(r)
    local fmt = '%Y%m%d%H%M%S'
    local timeout = 3600 -- 1 hour

    r.notes['zt-cert-timeout'] = timeout
    r.notes['zt-cert-date-next'] = os.date(fmt,os.time()+timeout)
    r.notes['zt-cert-date-halfnext'] = os.date(fmt,os.time()+ (timeout/2))
    r.notes['zt-cert-date-now'] = os.date(fmt,os.time())

    return apache2.OK
end

Kukilar sonini optimallashtirish va eski Cookie (token) muddati tugashiga yarim vaqt kelganda tokenni almashtirish bilan hammasi shunday ishlaydi:

SSLVerifyClient optional

#LuaScope thread
#generate event variables zt-cert-date-next
LuaHookAccessChecker /usr/local/etc/apache24/sslincludes/websocket_token.lua handler early

#Π·Π°ΠΏΡ€Π΅Ρ‰Π°Π΅ΠΌ Π±Π΅Π· сСртификата Ρ‡Ρ‚ΠΎ-Ρ‚ΠΎ Π΅Ρ‰Ρ‘, ΠΊΡ€ΠΎΠΌΠ΅ webscoket
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule     .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

#websocket for safari without certauth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
    SetEnvIf Cookie "zt-cert=([^,;]+),([^,;]+),[^,;]+,([^,;]+)" zt-cert-sha1=$1 zt-cert-date=$2 zt-cert-uid=$3

    <RequireAll>
        Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
        Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
        Require expr %{env:zt-cert-date} -ge %{env:zt-cert-date-now}
    </RequireAll>
   
    #Π·Π°ΠΌΠ΅Ρ‰Π°Π΅ΠΌ Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π²Π»Π°Π΄Π΅Π»ΡŒΡ†Ρƒ сСртификата Π½Π° Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π½ΠΎΠΌΠ΅Ρ€Ρƒ ΠΏΡ€ΠΎΡ‚ΠΎΠΊΠΎΠ»Π°
    SSLUserName SSl_PROTOCOL
    SSLOptions -FakeBasicAuth
</If>
</If>

<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
    SetEnvIf Cookie "zt-cert=([^,;]+),[^,;]+,([^,;]+)" HAVE_zt-cert-sha1=$1 HAVE_zt-cert-date-halfnow=$2
    SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1

    Define zt-cert "path=/;Max-Age=%{env:zt-cert-timeout};HttpOnly;Secure;SameSite=Strict"
    Define dates_user "%{env:zt-cert-date-next},%{env:zt-cert-date-halfnext},%{SSL_CLIENT_S_DN_CN}"
    Header set Set-Cookie "expr=zt-cert=%{sha1:salt1%{env:zt-cert-date-next}sal3%{SSL_CLIENT_S_DN_CN}salt2},${dates_user};${zt-cert}" env=!HAVE_zt-cert-sha1-found
</If>
</If>

SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1
Ρ€Π°Π±ΠΎΡ‚Π°Π΅Ρ‚,

Π° Ρ‚Π°ΠΊ Ρ€Π°Π±ΠΎΡ‚Π°Ρ‚ΡŒ Π½Π΅ Π±ΡƒΠ΄Π΅Ρ‚
SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge  env('zt-cert-date-now') && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1

Chunki LuaHookAccessChecker faqat Nginx ma'lumotlariga asoslangan kirish tekshiruvlaridan so'ng faollashadi.

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Manbaga havola Tasvirlar.

Yana bir narsa.

Umuman olganda, direktivalar Apache (ehtimol, Nginx) konfiguratsiyasida qanday tartibda yozilganligi muhim emas, chunki oxirida hamma narsa qayta ishlash sxemasiga mos keladigan foydalanuvchi so'rovi tartibiga qarab tartiblanadi. Lua skriptlari.

Tugatish:

Amalga oshirishdan keyin ko'rinadigan holat (maqsad):
xizmatlar va infratuzilmani boshqarish qo'shimcha dasturlarsiz (VPN) birlashtirilgan va xavfsiz IOS-da mobil telefondan foydalanish mumkin.

Maqsadga erishildi, veb-rozetkalar ishlaydi va sertifikatdan kam bo'lmagan xavfsizlik darajasiga ega.

Biz ZeroTech kompaniyasida Apple Safari va mijoz sertifikatlarini veb-rozetkalar bilan qanday bog'ladik

Manba: www.habr.com

a Izoh qo'shish