FortiGate Firewall SSL Inspection: Derin Denetim ve Muafiyet

FortiGate Firewall SSL inspection, FortiGate’in HTTPS bağlantısının içine bakabilmek için bağlantıyı açtığı ve kullanıcıya kendi imzaladığı bir sertifikayla yeniden kurduğu denetimdir. FortiOS’ta iki türü var. Sertifika denetimi bağlantıyı açmaz, yalnız sunucunun adına ve sertifikasına bakar. Derin denetim (deep inspection) bağlantıyı açar ve içindeki sayfayı, dosyayı, uygulamayı görür.

Derin denetimin bedeli güven zinciridir. Kullanıcının bilgisayarı FortiGate’in imzasına güvenmiyorsa her HTTPS sitesinde uyarı görür. Güvense bile bazı istemciler araya girilmesini kabul etmez: sertifikasını sabitleyen uygulamalar ve kullanıcıdan kendi sertifikasını isteyen siteler. FortiGate’in fabrika profili bankaları, sağlık sitelerini ve işletim sistemlerinin güncelleme sunucularını da hiç açmadan geçirir. “SSL inspection açınca banka siteleri bozulur mu?” sorusunun cevabı bu üç ayrıntıda. Üçünü de muafiyet bölümünde ölçtüm.

Bu yazı FortiGate Firewall ileri seviye rehberimizin 1. adımıdır. TLS’in nasıl çalıştığını TLS nedir yazımızda, sertifikayı kimin neden imzaladığını sertifika otoritesi yazımızda anlattık. Burada çalışan ağının internet çıkışına derin denetim takıyorum ve aynı test sunucusuna üç ayrı adla bağlanıp FortiGate’in hangisini açtığını, hangisini muaf tuttuğunu ölçüyorum.

Lab cihazım değerlendirme lisansıyla çalışıyor ve bu lisans derin denetimin iki parçasını kapatıyor. FortiGate yeniden imzaladığı sertifikaya 512 bitlik anahtar koyuyor ve güncel bir istemci bu sertifikayla bağlantı kurmuyor. Kurumun sertifika otoritesinden alt CA almak için gereken sertifika isteği de üretilemiyor.

Bu yüzden içerik ölçümlerini istemcinin güvenlik seviyesini yalnız lab için düşürerek aldım, kullanıcı bilgisayarlarının güven zincirini de Fortinet’in belgesinden aktarıyorum. Hangi satırın ölçüm, hangisinin aktarım olduğunu her bölümde ayrıca söylüyorum.

Lab’da üç sonuç öne çıktı:

1. FortiGuard aboneliği olmayan cihazda bankacılık kategorisi muafiyeti hiçbir siteyi tanımadı.
2. Sertifikasını sabitleyen bir istemci derin denetimden geçemedi.
3. Muaf tutulan adresten indirilen EICAR test dosyası antivirüse hiç görünmedi.

Örnekteki sınır kapısında mühürlü bir yükün içine bakmanın tek yolu gönderenin mührünü kesmektir. Görevli yükü inceler ve kapıları kendi mührüyle yeniden kapatır. Alıcı o mührü tanıyorsa yükü kabul eder, tanımıyorsa geri çevirir. FortiGate’te gönderenin mührü sunucunun sertifikası, kapının mührü de FortiGate’in yeniden imzaladığı sertifikadır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde çalışan ağının internet çıkışına SSL inspection kurarken izlediğimiz sırayı anlatır.

FortiGate SSL Inspection Nasıl Olmalı?

Derin denetim çalışanların internet çıkışına takılır. Kullanıcı bilgisayarları FortiGate’in imzasına, tercihen kurumun kendi sertifika otoritesi üzerinden güvenir. Sunucunun sertifikası geçersizse kullanıcı bunu yine görür. Banka, sağlık ve kişisel gizlilik siteleri muaf tutulur, derin denetimde bozulduğu bilinen uygulamalar da. Muafiyetler loglanır ve çalışanlar denetimden haberdar edilir.

Bu düzeni üç kaynak birlikte tarif ediyor:

1. Fortinet FortiOS 7.0 Best Practices, SSL/TLS deep inspection sayfası. Fortinet’e göre FortiGate derin denetimde bir alt CA gibi çalışır ve sertifikaları anında imzalar. Bu alt CA sertifikası genellikle kurumun kendi sertifika otoritesinden alınır, örneğin sertifika servisleri kurulu bir Windows sunucusundan. Kullanıcılar FortiGate’in imzaladığı sertifikaya güvenmeli ve zincir bilgisayarlarında yüklü kök sertifikaya ulaşmalıdır, yoksa denetlenen her sitede uyarı görürler. Çalışanlara iletişimlerinin bu denetime tabi olduğu ve gizliliklerinin garanti edilemeyeceği bildirilmelidir. Bankacılık ve kişisel sağlık siteleri gibi kategorilerde derin denetim istenmeyebilir: tam denetim profili oluşturulurken Finance and Banking (finans ve bankacılık), Health and Wellness (sağlık) ve Personal Privacy (kişisel gizlilik) kategorileri fabrika ayarında muaf gelir.
2. CISA’nın TA17-075A uyarısı (Mart 2017), HTTPS denetiminin TLS güvenliğini zayıflatması üzerine. CISA’ya göre birçok HTTPS denetim ürünü sunucunun sertifika zincirini doğru doğrulamıyor ve doğrulama hatalarını istemciye nadiren iletiyor. Bu yüzden istemci yanlış sunucuyla konuştuğunu fark etmiyor. Önerisi: denetim ürünü kullanan kurumlar, ürünün sertifika zincirini doğru doğruladığından ve uyarı ve hataları istemciye ilettiğinden emin olmalı.
3. Fortinet FortiOS 7.0 yönetim kılavuzu, derin denetim ve sertifika denetimi sayfaları. Kılavuz gizlilik ya da başka sebeplerle açılmayacak oturumların adrese, kategoriye ya da izin listesine göre muaf tutulabileceğini söylüyor ve kesin bir uyarı veriyor: Fortinet_CA_Untrusted sertifikası tarayıcıya asla yüklenmez.

Muafiyetin bir de yasal tarafı var. Sağlık verisi KVKK’da özel nitelikli kişisel veridir (6698 sayılı Kanun, madde 6). Çalışanın sağlık sitesindeki trafiğini açmamak bu yüzden de doğru varsayılandır. Kişisel verinin teknik korunmasını KVKK teknik tedbirler yazımızda anlattık.

Kararlar:

Sertifika Denetimi mi, Derin Denetim mi?

İki denetim de kuraldaki aynı alandan seçilir. Farkları kullanıcının gördüğü sertifikadadır:

1. Sertifika denetimi bağlantıyı açmaz. Fortinet’in kılavuzuna göre FortiGate yalnız SSL/TLS katmanına kadar olan başlıklara bakar. Kullanıcı sunucunun asıl sertifikasını görür, FortiGate sitenin adını okur ve web filtresi siteyi adından engelleyebilir. Kılavuz bu kipi gizlilik sebebiyle derin tarama istemeyen ama site erişimini denetlemek isteyen kurumlara öneriyor.
2. Derin denetim iki ayrı bağlantı kurar: biri kullanıcıyla, biri sunucuyla. Sunucunun asıl sertifikası FortiGate’te kalır, kullanıcıya FortiGate’in imzaladığı bir kopya gider. FortiGate sunucunun sertifikasına güveniyorsa kopyayı Fortinet_CA_SSL ile, güvenmiyorsa Fortinet_CA_Untrusted ile imzalar.

Üçüncü satır CISA’nın istediği davranıştır: sunucunun sertifikası şüpheliyse FortiGate bunu saklamaz, kullanıcının bilgisayarının asla güvenmeyeceği bir CA ile imzalar ve tarayıcı uyarıyı gösterir. Fortinet_CA_Untrusted sertifikasını bir bilgisayara yüklemek bu uyarıyı kalıcı olarak susturmak demektir. Fortinet’in kılavuzunun bu sertifika için “asla” demesinin sebebi budur.

Örnekteki sınır kapısının da iki mührü var. Birini, gönderenin mührü sağlam çıkan yüklere takar. Ötekini, mührü zaten şüpheli gelen yüklere: alıcı o mührü görünce yükü açmadan önce durup düşünmelidir.

FortiGate Derin Denetim Profili: Fabrika Ayarları

Security Profiles → SSL/SSH Inspection ekranında lab cihazımda dört hazır profil vardı: certificate-inspection, deep-inspection, custom-deep-inspection ve no-inspection. deep-inspection profilinin açıklaması Read-only deep inspection profile, yani salt okunur derin denetim profili. Komut satırından düzenlemeyi denedim, cihaz kabul etmedi:

value parse error before 'deep-inspection'
Command fail. Return code -657

Muafiyet listesini değiştirmek isteyen kurum ya düzenlenebilir hazır profil custom-deep-inspection ile çalışır ya da deep-inspection’ı kopyalar. Lab’da kopyalayamadım: değerlendirme lisansı yeni SSL profiline izin vermiyor (reached the maximum number of entries). Bu yüzden düzenleme gereken ölçümü custom-deep-inspection ile yaptım.

Profil formu (Security Profiles → SSL/SSH Inspection → deep-inspection):

1. Inspection method: Full SSL Inspection, yani tam SSL denetimi. SSL Certificate Inspection sertifika denetimidir.
2. CA certificate: Fortinet_CA_SSL. Kullanıcıya giden kopyaları imzalayan CA budur. Alanın yanındaki sarı uyarı işaretinin üstüne gelince arayüz şunu söylüyor: bu profil tam SSL denetimi kullanıyor ve sertifika tarayıcılara yüklenmedikçe kullanıcılar büyük olasılıkla sertifika uyarısı görecek. Download düğmesi bu CA’yı bilgisayarlara dağıtmak için indirir.
3. Untrusted SSL certificates: Allow (izin ver). Sunucunun sertifikası FortiGate’in güvendiği bir CA’dan gelmiyorsa bağlantı kurulur, ama kopya Fortinet_CA_Untrusted ile imzalanır. Block (engelle) bu bağlantıyı keser. Ignore (yok say) ise Fortinet’in kılavuzuna göre sunucunun sertifikasını güvenilirmiş gibi yeniden imzalar. CISA’nın uyarısındaki kusur tam olarak budur, seçilmez.
4. Server certificate SNI check: Enable. İstemcinin bağlanmak istediği ad (SNI) sunucunun sertifikasındaki adla karşılaştırılır. Kurallar ve muafiyetler bu adla çalışır.

Formun alt kısmındaki Common Options bölümü sertifikanın diğer kusurlarını yönetiyor. Süresi dolmuş (Expired certificates), iptal edilmiş (Revoked certificates) ve doğrulaması başarısız (Validation failed certificates) sertifikada fabrika ayarı Block. Doğrulaması zaman aşımına uğrayanda ise Keep Untrusted & Allow: bağlantı kurulur, ama sertifika güvenilmez sayılır. Komut satırındaki karşılığından ilgili satırlar (show full-configuration firewall ssl-ssh-profile deep-inspection):

    edit "deep-inspection"
        set comment "Read-only deep inspection profile."
        config ssl
            set inspect-all disable
            set client-certificate bypass
            ...
        config https
            set ports 443
            set status deep-inspection
            set proxy-after-tcp-handshake disable
            set client-certificate bypass
            ...
            set expired-server-cert block
            set revoked-server-cert block
            set untrusted-server-cert allow
            set cert-validation-timeout allow
            set cert-validation-failure block
            set sni-server-cert-check enable
            set min-allowed-ssl-version tls-1.1
        end
        ...
        set server-cert-mode re-sign
        set caname "Fortinet_CA_SSL"
        set untrusted-caname "Fortinet_CA_Untrusted"
        set ssl-exemption-ip-rating enable
        set ssl-exemption-log disable
        set ssl-anomaly-log enable

İki satır arayüzde görünmüyor ve yazının ilerisinde önemli olacak. client-certificate bypass, sunucu kullanıcıdan sertifika isterse bağlantıyı denetimsiz geçirir. ssl-exemption-log disable ise muaf tutulan bağlantıların fabrika ayarında loga düşmediğini söylüyor.

FortiGate Derin Denetimi Kurala Bağlamak

SSL profili kurala Policy & Objects → Firewall Policy → kural formundaki Security Profiles bölümünden, SSL Inspection alanından bağlanır. Lab’da çalışan ağının internet çıkış kuralı (kural 1) antivirüs ve web filtresiyle birlikte sertifika denetimi taşıyordu, onu deep-inspection’a aldım. Formda üç yer birlikte okunur:

1. Name, Incoming Interface ve Outgoing Interface: Ic ag internet cikisi, personel → dis-hatlar. Derin denetim kural başına seçilir; misafir ağının kuralı aynı anda sertifika denetiminde kalabilir.
2. AntiVirus ve Web Filter: personel-av ve site-engelleme. İkisi de HTTPS’in içini SSL alanının izin verdiği kadar görür.
3. SSL Inspection: deep-inspection. Seçilince alanın yanında bir uyarı işareti, altında da Decrypted Traffic Mirror satırı çıkıyor.

config firewall policy
    edit 1
        set name "Ic ag internet cikisi"
        set utm-status enable
        set ssl-ssh-profile "deep-inspection"
        set av-profile "personel-av"
        set webfilter-profile "site-engelleme"
    next
end

Ekran bu yazı için kaydetmeden çekildi: ölçümlerden sonra lab’da kural 1’i yeniden certificate-inspection’a aldım.

Test için internetteki bir web sunucusunu taklit eden bir HTTPS sunucusu kurdum (198.18.0.1). Sunucunun sertifikasında üç ad var: dosya.example.net, www.microsoft.com ve banka.example.net. Sertifikayı lab’daki ayrı bir test CA’sı imzaladı, FortiGate bu CA’yı tanımıyor. Çalışan ağındaki bir makineden her ada bağlanıp iki şeye baktım: kullanıcının gördüğü sertifikayı kimin imzaladığına ve test CA’sına güvenen bir istemcinin bağlantıyı kabul edip etmediğine.

echo | openssl s_client -connect 198.18.0.1:443 -servername dosya.example.net 2>/dev/null | openssl x509 -noout -issuer
curl -s -o /dev/null -w "%{http_code}" --cacert dis-ca.crt --resolve dosya.example.net:443:198.18.0.1 https://dosya.example.net/

Kural sertifika denetimindeyken üç ad da aynı sonucu verdi, kullanıcı sunucunun asıl sertifikasını gördü:

2026-10-04 08:52:02 UTC
dosya.example.net    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0
www.microsoft.com    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0
banka.example.net    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0

Derin denetime geçince sonuç ada göre ayrıldı:

2026-10-04 08:53:06 UTC
www.microsoft.com    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0
dosya.example.net    veren: issuer=C = US, ... CN = Fortinet Untrusted CA, ... curl(dis-ca): 000 cikis=60
www.microsoft.com    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0
banka.example.net    veren: issuer=C = US, ... CN = Fortinet Untrusted CA, ... curl(dis-ca): 000 cikis=60

Satırlar sırayla şunu söylüyor:

1. www.microsoft.com denetlenmedi. Kullanıcı asıl sertifikayı gördü, çünkü bu ad fabrika muafiyet listesinde. Muafiyet bölümünün konusu bu.
2. dosya.example.net açıldı ve güvenilmez diye imzalandı. FortiGate test CA’sını tanımadığı için kopyayı Fortinet_CA_Untrusted ile imzaladı. Test CA’sına güvenen istemci de kopyayı reddetti (curl 60, sertifika doğrulanamadı).
3. banka.example.net de açıldı. Adında banka geçmesi bir şey değiştirmedi, sebebi muafiyet bölümünde.

Ayarı kaydettikten yarım dakika içinde aldığım ilk denemede üç ad da hâlâ asıl sertifikayı gösteriyordu ve trafik logunda SSL işlemi yoktu. Kural değişikliği denetim motoruna hemen ulaşmıyor, yukarıdaki sonuçlar sonraki denemelerden. Bir değişikliği sınarken ilk denemeye güvenmeyin.

Değerlendirme Lisansında Derin Denetim: 512 Bitlik Anahtar

Test CA’sına güvenmeyen sıradan bir istemcinin Fortinet_CA_Untrusted uyarısını yok sayıp devam etmesi gerekir (curl’de -k). Lab’da -k ile de bağlantı kurulamadı, şifre çözme hatasıyla düştü:

curl: (35) OpenSSL/3.0.13: error:0A000119:SSL routines::decryption failed or bad record mac

Sebebi kullanıcıya giden kopyanın anahtarıydı:

subject=CN = dosya.example.net
issuer=C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = Fortinet Untrusted CA, emailAddress = support@fortinet.com
X509v3 Subject Alternative Name: 
    DNS:dosya.example.net, DNS:www.microsoft.com, DNS:banka.example.net
                Public-Key: (512 bit)

FortiGate kopyaya 512 bitlik bir RSA anahtarı koymuş. Bu, değerlendirme lisansının düşük şifreleme sınırı. Aynı lisans sertifika isteğinde de yalnız 512 bit kabul ediyor. Güncel istemciler bu boyuttaki anahtarı reddediyor ya da onunla el sıkışmayı tamamlayamıyor. TLS 1.2’ye inmek de yetmedi (rsa routines::data too large).

Bağlantıyı kurabilen tek bileşim şu oldu: TLS 1.2, imzasız RSA anahtar değişimi (AES128-SHA) ve istemcinin güvenlik seviyesi sıfır (@SECLEVEL=0). Aşağıdaki içerik ölçümlerini bu ayarla aldım:

curl -k --tls-max 1.2 --ciphers "AES128-SHA:@SECLEVEL=0" --resolve dosya.example.net:443:198.18.0.1 https://dosya.example.net/

Bu ayar yalnız lab içindir. Gerçek bir istemciyi 512 bitlik anahtara razı etmek, derin denetimin korumaya çalıştığı şeyi bozmak olur. Tam lisanslı bir cihazda kopyanın anahtar boyunu cihaz gelince ölçüp buraya ekleyeceğim.

FortiGate Derin Denetimle HTTPS’teki Dosyayı Görmek

Derin denetimin kazancını antivirüs gösterdi. FortiGate antivirüs yazımızda EICAR test dosyası, kural sertifika denetimindeyken HTTPS’ten üç denemenin üçünde de 68 bayt olarak inmişti. Aynı kural derin denetime alınınca aynı dosyayı iki addan ikişer kez indirdim:

2026-10-04 08:55:31 UTC
== dosya.example.net eicar.com.txt (a)
curl: (56) Recv failure: Connection reset by peer
HTTP 200, 0 bayt
== dosya.example.net eicar.com.txt (b)
HTTP 403, 4829 bayt
== www.microsoft.com eicar.com.txt (a)
HTTP 200, 68 bayt
== www.microsoft.com eicar.com.txt (b)
HTTP 200, 68 bayt

dosya.example.net adında antivirüs dosyayı gördü. Akış kipinin bilinen davranışı tekrarladı: ilk denemede bağlantı kesildi, ikincide uyarı sayfası (403) geldi. Antivirüs logunda iki deneme de virus="EICAR_TEST_FILE" ve action="blocked" olarak duruyor.

www.microsoft.com adında aynı dosya iki denemede de olduğu gibi indi. Muaf tutulan her ad antivirüsün, web filtresinin ve uygulama kontrolünün de kör noktasıdır. Muafiyet listesine eklenen her satır bu yüzden bir güvenlik kararıdır.

Neden Bazı Siteler Denetlenmez? FortiGate SSL Muafiyetleri

Bazı sitelerin derin denetimden geçmemesinin üç ayrı sebebi var:

1. Mahremiyet: banka ve sağlık sitelerinin trafiği açılmaz. Fabrika profili bu siteleri kategorisinden tanıyıp geçirir.
2. Sertifika sabitleme: bazı uygulamalar sunucunun hangi sertifikayı vereceğini önceden bilir, araya giren kopyayı reddeder.
3. İstemci sertifikası: bazı siteler kullanıcıdan kendi sertifikasını ister, FortiGate o sertifikayı taklit edemez.

Birincisini FortiGate kendisi çözüyor, ama abonelik istiyor. İkincisiyle üçüncüsü muafiyet yazılmazsa bağlantıyı bozuyor.

Fabrika Muafiyetleri: Banka, Sağlık ve Güncelleme Sunucuları

deep-inspection profilinin Exempt from SSL Inspection (SSL denetiminden muaf) bölümünde iki liste var. Web categories altında iki FortiGuard kategorisi, Addresses altında 30 adres grubu:

Komut satırında kategoriler numarayla duruyor (set fortiguard-category 31 ve 33). Adlarını get webfilter categories verdi: 31 Finance and Banking, 33 Health and Wellness. Fortinet’in en iyi uygulama sayfasının saydığı üçüncü kategori, 87 Personal Privacy, cihazda tanımlı ama bu fabrika profilinde yoktu. Kişisel gizlilik sitelerini de muaf tutmak isteyen kurum onu elle ekler.

Adres grupları joker karakterli alan adı nesneleri. Örnekler:

    edit "microsoft"
        set wildcard-fqdn "*.microsoft.com"
    edit "update.microsoft.com"
        set wildcard-fqdn "*update.microsoft.com"
    edit "Windows update 2"
        set wildcard-fqdn "*.windowsupdate.com"

www.microsoft.com testte bu yüzden muaf geçti. Fortinet listedeki adların gerekçesini tek tek yazmıyor. Ortak yanları şu: bağlantıyı çoğunlukla bir tarayıcı değil, bir uygulama ya da işletim sisteminin güncelleme servisi kurar. Bu tür istemciler kendi güven listesini taşıyabilir ve araya giren sertifikayı reddedebilir. Reddin nasıl göründüğünü sabitleme bölümünde ölçtüm.

FortiGuard Aboneliği Yoksa Banka Kategorisi Kimseyi Tanımaz

Kategori muafiyeti, sitenin hangi kategoride olduğunu FortiGuard’a sorarak karar verir. Lab cihazımın aboneliği yok. diagnose debug rating çıktısı bunu açıkça söylüyor:

Service      : Web-filter
Status       : Enable
License      : Unknown
...
IP                                             Weight    RTT Flags   TZ   FortiGuard-requests  Curr Lost Total Lost             Updated Time
12.34.97.18                                         0      0 DIFT     0                    40         38         38 

Web filtresi servisinin lisansı bilinmiyor ve FortiGuard’a giden 40 sorgunun 38’i cevapsız kalmış. banka.example.net adının testte açılmasının sebebi bu: FortiGate adın bir banka olduğunu öğrenemedi.

Aboneliği olmayan cihazda kategoriyi elle vermenin yolu yerel derecelendirmedir (Security Profiles → Web Rating Overrides, yani web derecelendirmesini geçersiz kılma). Adı Finance and Banking kategorisine koydum:

config webfilter ftgd-local-rating
    edit "banka.example.net"
        set rating 31
    next
end

Aynı ad bu kez muaf geçti:

2026-10-04 08:53:53 UTC
banka.example.net    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0
banka.example.net    veren: issuer=CN = Dis Test Root CA                  curl(dis-ca): 200 cikis=0
dosya.example.net    veren: issuer=C = US, ... CN = Fortinet Untrusted CA, ... curl(dis-ca): 000 cikis=60

Sonucu herhangi bir yerel derecelendirmenin değil kategorinin getirdiğini sınamak için adı bir de 52 Information Technology kategorisine koydum. Ad yeniden açıldı ve Fortinet Untrusted CA ile imzalandı. Muafiyeti adın kendisi değil, düştüğü kategori getiriyor.

Bunun pratik sonucu şu: aboneliği olmayan ya da süresi dolmuş bir FortiGate’te fabrika profilindeki banka ve sağlık muafiyetleri hiçbir siteyi tanımaz ve bu siteler sessizce açılır. Bu durumda kurumun kullandığı bankaların adları yerel derecelendirmeyle ya da Addresses listesine eklenen bir adres nesnesiyle muaf tutulur.

Muafiyetin çalıştığını görmek için logu açın. Fabrika ayarında muaf bağlantılar loga düşmüyor. custom-deep-inspection profilinde açtım (Log SSL exemptions, komut satırında set ssl-exemption-log enable), aynı üç adı denedim ve SSL loguna (execute log display, kategori 17) baktım. Bir satırda FortiGate’in açtığı ad, iki satırda iki ayrı muafiyet gerekçesi:

date=2026-10-04 time=11:59:40 ... type="utm" subtype="ssl" eventtype="ssl-anomaly" level="notice" vd="root" action="resign-as-untrusted" policyid=1 ... profile="custom-deep-inspection" ... sni="dosya.example.net" ... eventsubtype="certificate-anomaly" msg="Server certificate is re-signed as untrusted" hostname="dosya.example.net"
date=2026-10-04 time=11:59:40 ... type="utm" subtype="ssl" eventtype="ssl-exempt" level="notice" vd="root" action="exempt" policyid=1 ... profile="custom-deep-inspection" ... sni="banka.example.net" eventsubtype="local-category" cat=31 catdesc="Finance and Banking" hostname="banka.example.net" msg="SSL connection is exempted based on local category rating."
date=2026-10-04 time=11:59:40 ... type="utm" subtype="ssl" eventtype="ssl-exempt" level="notice" vd="root" action="exempt" policyid=1 ... profile="custom-deep-inspection" ... sni="www.microsoft.com" eventsubtype="address" hostname="www.microsoft.com" msg="SSL connection is exempted based on address."

Mesajlar Türkçesiyle: sunucu sertifikası güvenilmez olarak yeniden imzalandı, SSL bağlantısı yerel kategori derecelendirmesine göre muaf tutuldu, SSL bağlantısı adrese göre muaf tutuldu. eventsubtype alanı muafiyetin gerekçesini (address, local-category) ayrı bir alan olarak taşıyor, log sunucusunda bu alana göre süzmek kolay.

Sertifikasını Sabitleyen Uygulamalar Neden Bozulur?

Sertifika sabitleme (certificate pinning), bir uygulamanın bağlandığı sunucunun hangi anahtarı kullanacağını önceden bilmesi ve başka bir anahtarla gelen sertifikayı, imzalayan kim olursa olsun reddetmesidir. Derin denetimde kullanıcıya giden kopyanın anahtarı FortiGate’indir. Sabitleme yapan uygulama bu yüzden kopyayı reddeder.

Bunu curl’ün sabitleme seçeneğiyle (--pinnedpubkey) ölçtüm. Önce test sunucusunun asıl açık anahtarının özetini aldım, sonra iki ada bu özetle bağlandım:

P=$(openssl x509 -in sunucu.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64)
curl -k --tls-max 1.2 --ciphers "AES128-SHA:@SECLEVEL=0" --pinnedpubkey "sha256//$P" --resolve dosya.example.net:443:198.18.0.1 https://dosya.example.net/

sabitlenen anahtar: sha256//U4oFIq9E9F/mEu2fbLOQ60DiuKhMWRUZtU89YUErHjw=
2026-10-04 08:55:31 UTC
== dosya.example.net sabitleme (pinnedpubkey)
curl: (90) SSL: public key does not match pinned public key
HTTP 000
cikis=90
== www.microsoft.com sabitleme (pinnedpubkey)
HTTP 200
cikis=0

Denetlenen adda curl bağlantıyı açık anahtar sabitlenen anahtarla eşleşmiyor diye reddetti (çıkış 90). Sertifika doğrulamasını kapatmış olmam (-k) bir şey değiştirmedi: sabitleme imzaya değil anahtara bakıyor. Muaf adda aynı komut 200 aldı.

Tarayıcı neden bozulmuyor? Chromium’un güvenlik SSS’i anahtar sabitlemenin yerel vekil sunucular ve filtrelerle ilişkisini şöyle anlatıyor: sertifika zinciri kullanıcının ya da yöneticinin yüklediği özel bir kök sertifikaya çıkıyorsa Chrome sabitlemeyi denetlemez. Gerekçesi de açık: vekil sunucu ancak istemci onun sertifikasına güvenecek biçimde ayarlanmışsa araya girebilir, bu da istemcinin zaten vekili yönetenin denetiminde olduğu anlamına gelir.

Yani FortiGate’in CA’sı bilgisayara yüklenmişse tarayıcı bankanın sitesini açar.

Mobil uygulama aynı kolaylığı tanımıyor. Android 7.0’dan beri bu sürümü hedefleyen uygulamalar, açıkça izin vermedikçe kullanıcının ya da yöneticinin eklediği CA’lara güvenmiyor. Kurumun Wi-Fi’ına bağlı bir telefondaki bankacılık uygulaması bu yüzden derin denetimde bağlanamayabilir, telefona FortiGate’in CA’sı yüklenmiş olsa bile. Çözüm muafiyettir: uygulamanın bağlandığı adres bilinmiyorsa kategori, biliniyorsa adres.

İstemci Sertifikası İsteyen Siteler

Bazı siteler kullanıcıdan kendi sertifikasını ister ve kimliği parolayla değil bu sertifikayla doğrular. Sertifikanın özel anahtarı kullanıcının bilgisayarında ya da akıllı kartında durur. FortiGate onu taklit edemez: Fortinet’in bilgi bankası makalesine göre FortiGate derin denetim yaparken istemci sertifikasını sunucuya iletemez. Profildeki client-certificate seçeneğinin üç değeri bu yüzden var:

1. bypass: oturum derin denetimden muaf tutulur ve istemci sertifikası sunucuya ulaşır. Fabrika profili HTTPS için bunu kullanıyor.
2. inspect: oturum denetlenir ama sertifika sunucuya gitmez, bağlantı kopabilir.
3. block: oturum engellenir.

Lab’da ikinci bir test sunucusu kurdum (198.18.0.2, istemci.example.net). Sunucu bağlanan herkesten test CA’sının imzaladığı bir kullanıcı sertifikası istiyor. Kullanıcı sertifikasıyla, TLS 1.2 ve yukarıdaki lab ayarıyla üç kez bağlandım:

2026-10-04 08:56:13 UTC
== TLS 1.2 deneme 1, istemci sertifikasiyla (-k, SECLEVEL=0)
curl: (35) OpenSSL/3.0.13: error:0A00041B:SSL routines::tlsv1 alert decrypt error
HTTP 000
cikis=35
== TLS 1.2 deneme 2, istemci sertifikasiyla (-k, SECLEVEL=0)
HTTP 200
cikis=0
== TLS 1.2 deneme 3, istemci sertifikasiyla (-k, SECLEVEL=0)
HTTP 200
cikis=0
== TLS 1.2, normal guvenlik, dis-ca ile dogrulama
HTTP 200
cikis=0

İlk bağlantı koptu. FortiGate o bağlantıda sunucunun sertifika istediğini öğrendi ve sonrakileri denetimsiz geçirdi. Son satır bunun kanıtı: güvenlik seviyesi düşürülmemiş, yalnız test CA’sına güvenen bir istemci bağlantıyı kabul etti. Yani kullanıcı sunucunun asıl sertifikasını gördü. Öğrenmeden sonra fabrika ayarındaki TLS 1.3 istemci de iki denemede 200 aldı.

Kullanıcının göreceği şey şu: böyle bir siteye günün ilk girişi hata verir, sayfayı yenileyince açılır. Kullanıcı bunu “site bazen açılmıyor” diye bildirir. Bu tür siteleri baştan adres muafiyetine yazmak ilk hatayı da ortadan kaldırır. Öğrenmeden önceki TLS 1.3 denemeleri lab’da 512 bitlik anahtar yüzünden istemcide düştü, bu yüzden FortiGate’in TLS 1.3’te de aynı biçimde öğrendiğini ölçemedim.

Kullanıcı Bilgisayarı FortiGate’in Sertifikasına Nasıl Güvenir?

Bu bölümü lab’da ölçemedim, Fortinet’in belgesinden aktarıyorum. Değerlendirme lisansı ne kurum CA’sı için sertifika isteği üretmeye ne de CA sertifikası içe aktarmaya izin veriyor:

Supported key size: 512.
Command fail. Return code 1

Arayüzden CA sertifikası içe aktarma denemesi de her biçimde Incorrect certificate file format for CA/LOCAL/CRL/REMOTE cert. hatasıyla, yani sertifika dosyasının biçimi yanlış diye reddedildi.

İki yol var:

1. Fortinet_CA_SSL’i dağıtmak. Fortinet’in kılavuzuna göre profil formundaki Download düğmesiyle CA indirilir ve kullanıcı bilgisayarında sertifika içe aktarma sihirbazıyla Trusted Root Certification Authorities deposuna yüklenir. Domain ortamında bu iş tek tek bilgisayarda değil, Group Policy ile bütün bilgisayarlara yapılır. Lab’da bu CA’nın imzaladığı bir kopyada veren adı (CN) cihazın seri numarasıydı (FGVMEVBT4WPKUKAA), yani CA cihaza özgü: cihaz değişirse sertifika yeniden dağıtılır.
2. Kurumun CA’sından alt CA almak. Fortinet’in en iyi uygulama sayfasına göre FortiGate genellikle kurumun kendi CA’sının imzaladığı bir alt CA sertifikası kullanır. Alt CA sertifikası özel anahtarıyla birlikte FortiGate’e yüklenir ve profilin CA certificate alanında seçilir. Anahtarın cihazdan hiç çıkmaması istenirse sertifika isteği FortiGate’te üretilir, lab’da bu adım yukarıdaki 512 bit sınırına takıldı. Bilgisayarlar kurumun kök sertifikasına zaten güvendiği için ayrıca bir şey dağıtılmaz. Active Directory’si olan kurumda bu CA, AD sertifika servisleri üzerindeki alt CA şablonuyla imzalanır. Zincirin nasıl kurulduğunu sertifika otoritesi yazımızda anlattık.

İkinci yolun bir kazancı daha var: alt CA’nın süresini ve iptalini kurumun CA’sı yönetir. Cihaz çalınırsa ya da değiştirilirse kurumun CA’sı alt CA’yı iptal eder, bilgisayarlardan tek tek sertifika silmek gerekmez.

İki yolda da Fortinet_CA_Untrusted hiçbir bilgisayara yüklenmez. Cihaz gelince iki yolu da lab’da ölçüp bu bölüme ekleyeceğim.

Doğrulama: FortiGate SSL Inspection Doğru Çalışıyor mu?

1. Kural: çalışanların internet çıkış kuralında SSL Inspection alanı derin denetim profilini gösteriyor. Değişiklikten sonraki ilk deneme sayılmıyor.
2. Sertifika: denetlenen bir sitede openssl s_client -servername {ad} çıktısındaki issuer satırı Fortinet_CA_SSL’i ya da kurumun alt CA’sını gösteriyor. Geçersiz sertifikalı bir test sitesinde kullanıcı yine uyarı görüyor.
3. Muafiyet: muaf olması gereken bir adda issuer sunucunun kendi CA’sı. Log SSL exemptions açık ve logda exempted based on satırları var.
4. Abonelik: diagnose debug rating çıktısında web filtresinin lisansı geçerli. Değilse banka ve sağlık siteleri adres ya da yerel derecelendirmeyle muaf tutulmuş.
5. Kullanıcı bilgisayarları: Fortinet_CA_SSL ya da kurumun kök sertifikası güvenilen depoda, Fortinet_CA_Untrusted hiçbir yerde yok.
6. Bozulanlar: mobil bankacılık uygulaması ve istemci sertifikası isteyen siteler ilk denemede açılıyor, çünkü adresleri muafiyete yazılmış.
7. Bildirim: çalışanlara internet trafiğinin derin denetimden geçtiği yazılı olarak bildirilmiş.

Sonuç: FortiGate Derin Denetim, Neyin Açılmayacağını Bilmekle Başlar

FortiGate’te derin denetimi açmak tek bir alan seçmektir. Asıl iş, hangi bağlantının açılmayacağına karar vermek ve bunun bedelini bilmektir. Lab’da dört şey öne çıktı:

1. Derin denetim kullanıcıya hiçbir zaman sunucunun asıl sertifikasını vermiyor. Güvenilmeyen sunucunun kopyası Fortinet_CA_Untrusted ile imzalandı ve uyarı kullanıcıya ulaştı.
2. Banka kategorisi muafiyeti abonelik istiyor. FortiGuard’a ulaşamayan cihaz bankayı taklit eden adı açtı, aynı ad yerel derecelendirmeyle muaf geçti.
3. Sertifikasını sabitleyen istemci derin denetimde bağlanamadı, muaf adda bağlandı. İstemci sertifikası isteyen sitede ilk bağlantı koptu, sonrakiler denetimsiz geçti.
4. Muaf ad bütün güvenlik profillerinin kör noktası. Muaf addan EICAR test dosyası olduğu gibi indi.

Örnekteki sınır kapısında bazı yükler mühürleri kesilmeden geçer: diplomatik çantalar, alıcısı mührün seri numarasını tanıyan yükler ve teslimde alıcının kendi imzasını isteyen gönderiler. Kapı bu yüklerin listesini bilerek tutar ve her birinin içine bakmadığını kabul eder. FortiGate’te bu liste muafiyetlerdir. Sıradaki adım rehberin 2. adımı, HTTPS’te artık sayfanın tamamını görebilen web filtresi.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn