IP Kamera ve NVR’da HTTPS Sertifika Yönetimi: CA, CSR ve Yenileme

Kameranın web arayüzünde “Bağlantınız gizli değil” uyarısını ilk kez gören teknisyen durur ve okur. Onuncu seferde okumaz, doğrudan “Devam et”e basar. Asıl risk de burada başlar: ortadaki adam saldırısında sunulan sahte sertifika da aynı uyarıyı üretir ve aynı tıklamayla geçilir. Aşağıda kamera sistemleri sorumluları için kurum içi CA ile sertifika üretmeyi, CSR ve yükleme sırasını, hangi protokolün gerçekten şifreli olduğunu, OpenSSL ile doğrulamayı ve yenilemenin nasıl takip edileceğini sahadaki uygulama sırasıyla veriyoruz.

Kamerada HTTPS neden çoğu zaman eksik kalır

Kameraların çoğu fabrikadan ya yalnız HTTP ile ya da cihazın kendi ürettiği self-signed sertifikayla çıkar. Devreye almada öncelik görüntü ve kayıttır; HTTPS “sonra bakarız” listesine yazılır ve orada kalır. Mevcut bir kamera ağını denetlerken karşımıza çıkan tablo genellikle şudur:

• HTTP (80) ve HTTPS birlikte açık; HTTPS self-signed, kullanıcılar uyarıyı geçmeye alışmış.
• VMS kameralara HTTP ile bağlanıyor. Parola Digest ile gitse bile oturumun geri kalanı açık metin.
• Sertifikanın konu adında kameranın eski IP adresi yazıyor; adres değişmiş, fark eden olmamış.
• NVR sertifikası ilk kurulum tarihiyle üretilmiş ve süresi dolmuş; mobil istemci bağlantı hatası veriyor, nedenini bilen yok.

Self-signed sertifika trafiği şifreler ama karşıdaki cihazın kim olduğunu kanıtlamaz. İstemcinin elinde “doğru” sertifikayı ayırt edecek bir referans yoktur; saldırganın sunduğu başka bir self-signed sertifika da aynı uyarıyla kabul edilir. Eksik olan şifreleme değil. Eksik olan doğrulanabilir kimliktir.

Self-signed, kurum içi CA mı, genel CA mı

Seçenek	Avantaj	Sınırlama	Uygun senaryo
Self-signed	Ek altyapı gerektirmez	Kimlik doğrulanamaz, uyarı alışkanlığı yaratır	Yalnız ilk kurulum ve laboratuvar
Kurum içi CA (AD CS, step-ca vb.)	İç alan adı ve IP için sertifika, süre kurum kontrolünde	CA’nın kendisi korunmalı, kök sertifika istemcilere dağıtılmalı	Kurumsal kamera ağı, VMS ve operatör istasyonları
Genel CA	Her tarayıcı otomatik güvenir	Özel IP ve .local gibi iç alan adına sertifika verilmez; süreler kısalıyor	Yalnız internete açık bir VMS ağ geçidi veya web istemcisi

Kamera ağı internete kapalı olması gereken bir segmenttir; bu yüzden pratik cevap neredeyse her zaman kurum içi CA’dır. Active Directory varsa AD CS altında bir alt CA ve kamera sertifikaları için ayrı bir şablon açmak en az sürtünmeli yoldur. AD yoksa çevrimdışı kök ve çevrimiçi alt CA yapısında çalışan açık kaynak bir CA iş görür. Kural tektir: kök CA’nın özel anahtarı kamera ağındaki hiçbir sistemde bulunmaz.

Genel CA sertifikalarının azami geçerlilik süresi CA/Browser Forum kararlarıyla kademeli olarak kısalıyor. Yüzlerce cihazda elle yenileme bu tempoda sürdürülemez. Kurum içi CA’da kamera sertifikası için bir veya iki yıllık süre, yenileme süreci oturana kadar makul bir başlangıçtır; süreç otomasyona bağlandıkça kısaltılabilir.

CSR oluşturma ve sertifika yükleme sırası

1. Önce ad ve DNS, sonra sertifika

Sertifika bir ada verilir; adı belirsiz cihaza düzgün sertifika verilmez. Her kameraya kalıcı bir DNS adı verin (ör. cam-b1-012.cctv.kurum.local) ve DHCP rezervasyonu veya statik IP ile eşleyin. Sertifikada hem bu ad hem IP adresi Subject Alternative Name (SAN) alanında yer almalı. Chrome başta olmak üzere modern tarayıcılar ad doğrulamasında CN alanına bakmaz. SAN’sız sertifika, CA’nız güvenilir olsa bile hata verir; “kök sertifikayı dağıttık ama uyarı hâlâ çıkıyor” şikâyetinin en sık nedeni budur.

2. Özel anahtar nerede üretilecek

Kamera cihaz üzerinde CSR üretebiliyorsa bu yolu seçin: özel anahtar cihazdan hiç çıkmaz. Bazı modeller anahtarı güvenli eleman veya TPM benzeri bir donanımda tutar. Cihaz CSR üretemiyorsa anahtarı yönetim sunucusunda üretir, PKCS#12 paketi olarak yüklersiniz. Bu durumda işlem biter bitmez anahtar dosyalarını güvenli biçimde silin. Masaüstünde unutulan bir .key dosyası bütün emeği boşa çıkarır.

# Cihaz CSR üretemiyorsa: anahtar + SAN içeren CSR (OpenSSL 1.1.1 ve üzeri)
openssl req -new -newkey rsa:2048 -nodes \
  -keyout cam-b1-012.key -out cam-b1-012.csr \
  -subj "/CN=cam-b1-012.cctv.kurum.local" \
  -addext "subjectAltName=DNS:cam-b1-012.cctv.kurum.local,IP:10.20.30.12"

# CSR içeriğini kontrol
openssl req -in cam-b1-012.csr -noout -text

# AD CS'e gönderim (Web Server şablonu veya kameraya özel şablon)
certreq -submit -attrib "CertificateTemplate:WebServer" cam-b1-012.csr cam-b1-012.cer

# Anahtar, sertifika ve zinciri tek pakette birleştirme
openssl pkcs12 -export -inkey cam-b1-012.key -in cam-b1-012.cer \
  -certfile kurum-ca-zinciri.pem -out cam-b1-012.p12

AD CS şablonunda konu adının “istekte sağlanır” olarak ayarlandığını kontrol edin; aksi halde CSR’daki SAN sertifikaya taşınmaz, sertifika sorunsuz görünür ama tarayıcı yine ad hatası verir. İkinci tuzak OpenSSL 3.x’tir: ürettiği PKCS#12 dosyaları varsayılan olarak daha güçlü şifreleme kullanır ve bazı eski kamera firmware’leri bu dosyayı okuyamaz. Yükleme “geçersiz dosya” hatasıyla dönüyorsa -legacy seçeneğiyle yeniden paketlemek gerekebilir; ama önce firmware güncellemesini değerlendirin.

3. Yükleme ve HTTPS’i zorlama

1. Önce kurum CA zincirini (kök ve alt CA) kameranın güvenilir CA deposuna yükleyin.
2. Cihaz sertifikasını yükleyin ve HTTPS servisine atayın.
3. VMS’te kamera bağlantısını HTTPS’e çevirin ve sertifika doğrulamasını açın; ardından görüntü, PTZ ve olay akışını tek tek test edin.
4. Her şey çalışınca HTTP’yi kapatın veya HTTPS’e yönlendirin. ONVIF’in hangi portu kullandığını kontrol etmeden HTTP’yi kapatırsanız VMS entegrasyonu sessizce kırılır.
5. Minimum TLS sürümünü TLS 1.2 yapın; firmware izin veriyorsa zayıf şifre takımlarını kapatın.

Yüzlerce kamerada bu iş elle yapılmaz. Birçok üreticinin cihaz yönetim yazılımı veya HTTP API’si toplu sertifika dağıtımını destekler; desteği model ve firmware bazında doğrulayın, önce küçük bir pilot grupta deneyin. Pilotta çıkmayan sorun sahada toplu çıkar.

Hangi protokol gerçekten şifreli: HTTP, RTSP, RTSPS, ONVIF

HTTPS açıldı diye kameranın bütün trafiği şifrelenmiş olmaz. Tabloda kamera ağında sık rastlanan uç noktalar ve tipik varsayılan portlar var; gerçek portlar üreticiye ve yapılandırmaya göre değişir.

Uç nokta	Tipik port	Şifreleme	Not
HTTP	TCP 80	Yok	Kapatılmalı veya HTTPS’e yönlendirilmeli
HTTPS	TCP 443	TLS	Web arayüzü ve API
RTSP	TCP 554	Yok	Kimlik doğrulama Digest olabilir; görüntü açık
RTSPS	TCP 322	TLS	Kamera ve VMS desteği birlikte gerekir
ONVIF	Çoğunlukla HTTP portu	HTTPS’e taşınabilir	VMS’in HTTPS üzerinden ONVIF desteğini doğrulayın

rtsps şeması ve 322 numaralı varsayılan port RFC 7826 ile tanımlıdır; ancak sahadaki cihazların büyük bölümü RTSP 1.0 konuşur ve RTSPS desteği üreticiye göre değişir. Bazı üreticiler RTSP’yi HTTPS içinde tünelleyerek veya SRTP ile medya şifrelemesi sunar. Görüntü akışını şifreleyemiyorsanız akışın yalnız kamera VLAN’ı ile kayıt sunucusu arasında kalmasını ağ tarafında sağlamanız gerekir. Şifre yoksa sınır olmalı. İzin verilen akışları kamera trafik matrisi ve ACL tasarımı rehberinde satır satır çıkardık.

OpenSSL ile doğrulama

Arayüzde “sertifika yüklendi” yazması yetmez. Kameranın gerçekte hangi sertifikayı sunduğunu, zincirin tam olup olmadığını ve hangi TLS sürümlerini kabul ettiğini istemci tarafından kontrol edin:

# Sunulan sertifika ve zincir
openssl s_client -connect 10.20.30.12:443 \
  -servername cam-b1-012.cctv.kurum.local -showcerts </dev/null

# Konu, yayıncı, tarih ve SAN alanı
openssl s_client -connect 10.20.30.12:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Kurum zinciriyle doğrulama
openssl verify -CAfile kurum-ca-zinciri.pem cam-b1-012.cer

# TLS 1.2 kabul ediliyor mu?
openssl s_client -connect 10.20.30.12:443 -tls1_2 </dev/null

# TLS 1.1 reddediliyor mu? (OpenSSL 3.x istemcide SECLEVEL düşürülmeli)
openssl s_client -connect 10.20.30.12:443 -tls1_1 \
  -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

# 30 gün içinde süresi doluyor mu? (doluyorsa çıkış kodu 1)
openssl x509 -in cam-b1-012.cer -noout -checkend 2592000

s_client çıktısında “Verify return code: 0 (ok)” görmek için -CAfile ile kurum zincirini vermeniz gerekir. Çıktıda yalnız cihaz sertifikası görünüyor, ara CA yoksa kameraya zincir eksik yüklenmiştir. Tarayıcı bunu tolere edebilir, VMS veya mobil istemci reddedebilir; “bende açılıyor, operatörde açılmıyor” vakalarının tipik nedeni budur. TLS 1.1 denemesinde el sıkışma tamamlanıyorsa kamera eski protokolü hâlâ kabul ediyordur. Bir tuzak daha var: OpenSSL 3.x istemci varsayılan güvenlik seviyesinde TLS 1.1’i kendisi reddeder, @SECLEVEL=0 eklenmeden yapılan test yanlış güven verir.

Yenileme takibi ve otomasyon

Sertifika projesinin asıl yükü ilk kurulum değil, yenilemedir. Aynı gün kurulan iki yüz sertifikanın süresi de aynı gün dolar. Arıza kaydı da toplu gelir. Uygulanabilir bir düzen şöyle kurulur:

• Envanterde sertifika alanları: her kamera ve NVR için seri numarası, bitiş tarihi, yayıncı CA ve SAN değerleri tutulur. Alan yapısı için kamera envanteri nasıl tutulur rehberine bakabilirsiniz.
• Periyodik tarama: kamera IP listesi üzerinde gece çalışan bir betik, her cihazın sunduğu sertifikayı s_client ile çeker ve -checkend ile 60/30/7 gün eşiklerinde uyarı üretir. Envanterde yazan ile cihazın gerçekte sunduğu sertifika arasındaki fark da bu taramada ortaya çıkar.
• İzleme sistemine bağlama: mevcut izleme platformunuz TLS sertifika süresi kontrolünü destekliyorsa kamera ve NVR’ları ekleyin; alarmı kamera sisteminden sorumlu ekibe yönlendirin.
• Otomatik yenileme: bazı üreticiler ACME veya SCEP ile otomatik yenilemeyi desteklemeye başladı. Destek varsa kurum içi CA’nın bu protokolü sunup sunmadığını ve kameranın CA’ya hangi yoldan erişeceğini ACL ile birlikte planlayın.
• Firmware ilişkisi: firmware güncellemesi bazı cihazlarda sertifika deposunu sıfırlayabilir. Güncelleme sonrası kontrol listesine sertifika doğrulamasını ekleyin.

Sahada en sık görülen hatalar

• SAN’sız sertifika: CN doğru olsa bile tarayıcı ad uyuşmazlığı hatası verir.
• Yanlış saat: NTP’siz kamera 1970’e veya fabrika tarihine döndüğünde sertifika “henüz geçerli değil” görünür. Sertifika işine NTP kontrolüyle başlayın.
• VMS’in doğrulama yapmaması: kameralara güvenilir sertifika yüklenip VMS’te sertifika doğrulaması kapalı bırakılırsa koruma yalnız tarayıcı tarafında kalır.
• Kök sertifikanın dağıtılmaması: operatör istasyonları ve mobil cihazlar kurum CA’sına güvenmiyorsa kullanıcılar yine uyarı görür ve yine geçer. Kök sertifikayı grup ilkesi veya MDM ile dağıtın.
• Özel anahtarların ortada kalması: dışarıda üretilen anahtar ve PKCS#12 dosyaları paylaşılan klasörde unutulursa sertifikanın verdiği kimlik güvencesi biter.
• HTTPS’i tek önlem saymak: varsayılan parolalar, açık servisler ve eski firmware yerinde dururken HTTPS yalnız trafiği korur. Genel sıkılaştırma için IP kamera ve NVR siber güvenlik kontrol listesi başlangıç noktasıdır.

Kamera filosunda HTTPS geçişini envanter, CA tasarımı ve VMS uyumluluk testleriyle birlikte yürütüyoruz; kapsam için IP kamera ve NVR siber güvenlik sıkılaştırması sayfasına bakabilirsiniz. Firmware kaynaklı sertifika sorunlarını firmware güncelleme yönetimi ile birlikte ele almak gerekir.

Sık sorulan sorular

Kamerada HTTPS açmak RTSP görüntü akışını da şifreler mi?

Hayır. HTTPS yalnız web arayüzünü ve HTTPS üzerinden giden API çağrılarını korur. RTSP ayrı bir protokoldür; akışın şifrelenmesi için kamera ve VMS’in RTSPS, SRTP veya RTSP over HTTPS tünelini birlikte desteklemesi gerekir.

Kameralar için Let’s Encrypt gibi genel bir CA kullanılabilir mi?

Genel CA’lar özel IP adreslerine ve .local gibi kuruma ait olmayan iç alan adlarına sertifika vermez. Kurumun sahip olduğu bir alan adının alt adı DNS doğrulamasıyla alınabilir; ama kısalan geçerlilik süreleri yüzlerce kamerada sık yenileme demektir ve ad, sertifika şeffaflık kayıtlarında herkese açık görünür. Kapalı bir kamera ağında kurum içi CA daha uygundur.

Sertifika süresi dolarsa kayıt durur mu?

Çoğu sistemde kayıt RTSP üzerinden aktığı için durmaz. Ancak VMS sertifikayı doğruluyorsa kamera bağlantısı kesilebilir; tarayıcı ve mobil istemciler hata verir. Etkisi VMS’in doğrulama ayarına bağlıdır. Yenilemeyi süre dolmadan planlayın.

Sertifikada IP adresi mi DNS adı mı olmalı?

İkisi de SAN alanına yazılabilir. DNS adı IP değişikliğinde sertifikayı geçerli tutar; IP adresi ise DNS kullanmayan VMS bağlantıları için gerekir. Tarayıcılar CN alanını dikkate almaz, hangisini kullanıyorsanız SAN’da bulunmalıdır.