Self-Signed OCSP Responder Sertifikası ile Smart Card Login Hatasını Çözme (CLI ile)

Kurumsal ortamlarda Smart Card (Akıllı Kart) ile giriş kullanımı güvenlik açısından oldukça yaygındır. Ancak bu yapıların düzgün çalışması için sertifika doğrulama zincirinin yanında sertifikanın iptal edilip edilmediğini de kontrol eden mekanizmaların sağlıklı yapılandırılmış olması gerekir.

Bu noktada devreye OCSP (Online Certificate Status Protocol) girer.

OCSP kısaca şunu yapar; Sertifikanın geçerli mi yoksa iptal edilmiş mi olduğunu, iptal listesini (CRL) indirmeden online olarak sorar.

Bu makalemde vCenter üzerinde OCSP doğrulaması yapılırken özellikle kurum içerisinde kullanılan local (özel) OCSP responder’a yönlendirme yapıldığında oluşan kritik bir hata senaryosunu ve çözüm yolunu ele alacağız.

Özellikle odaklandığımız konu şu:

• Self-signed responder certificate kullanıldığında vCenter bu sertifikaya güvenmeyebilir
• UI’dan her şey doğru görünse bile login hatası alabilirsiniz
• Çözüm genelde GUI’de değil, CLI tarafında gizlidir

Senaryo: Local OCSP Responder ile login hatası

Bir müşteride vCenter SSO için OCSP revocation checking açılıyor. Ama müşteri sertifikanın içinde gömülü OCSP URL’si yerine kendi ağındaki OCSP sunucusunu kullanmak istiyor.

Bu yüzden yapılandırma şu şekilde ilerliyor:

• vCenter üzerinde OCSP kontrolü açılıyor
• OCSP URL kurumdaki sunucuya veriliyor (örn: http://ocsp.kadirkozan.local)
• Smart Card kullanıcıları giriş yapmaya çalışıyor

Ve sonuç; Smart Card ile girişler başarısız.

Ekranda görünen hata:

Login error – Unable to validate submitted credential.

Bu hata tek başına çok açıklayıcı değildir çünkü temel sebep çoğunlukla arka planda loglarda saklıdır.

Log analizi: Asıl problem sso-websso tarafında

Bu tarz hatalarda ilk yapılması gereken iş: vCenter SSO loglarını incelemektir.

/var/log/vmware/sso/ veya benzeri log dizinlerinde sso-websso loguna baktığınızda aşağıdaki hata tipik olarak karşınıza çıkar:

Caused by: java.security.cert.CertPathValidatorException:
Responder's certificate is not authorized to sign OCSP responses

Ayrıca şuna benzer bir mesaj:

com.vmware.identity.idm.CertRevocationStatusUnknownException:
Unable to validate certificate path.
Message: [Responder's certificate is not authorized to sign OCSP responses]
Reason: [UNSPECIFIED]

Bu mesaj çoğu kişinin aklına şu ihtimali getirir:

“OCSP responder sertifikasında OCSP Signing Key Usage eksik.”

Çünkü gerçekten de OCSP responder sertifikasında şu özellik olmazsa bu hata çıkar:

• Extended Key Usage: OCSP Signing

Fakat bu senaryoda önemli ayrım şu:

• Sertifika aslında doğru hazırlanmıştı
• OCSP Signing EKU mevcuttu
• Buna rağmen login fail oluyordu

Yani sorun sertifikanın içeriğinde değil vCenter’ın bu sertifikaya güvenmemesinde.

Gerçek neden: vCenter, responder sertifikasını “trusted” saymıyor

OCSP responder şunu yapar:

• Smart Card sertifikasının iptal durumuna dair bir cevap üretir
• Bu cevabı responder, kendi signing certificate’ıyla imzalar

Dolayısıyla vCenter şu doğrulamayı yapmak zorundadır:

“Bu cevabı imzalayan sertifikaya güvenebilir miyim?”

Eğer güvenemezse sonuç şudur:

• Sertifika iptal değil bile olsa
• OCSP cevabı doğrulanamadığı için
• vCenter girişe izin vermez

VMware dokümantasyonunda şu cümle geçer:

Eğer OCSP cevabını üreten CA, smart card sertifikasının signing CA’sından farklıysa, OCSP signing CA sertifikasını sağlamalısınız.

İşte burada problem çıkar çünkü:

• OCSP responder sertifikası self-signed
• Yani bunun arkasında “kurumsal CA zinciri” yok
• vCenter bunu otomatik güvenilir kabul etmez

Neden “Trusted CA Store’a ekleyeyim” çözmüyor?

İlk akla gelen çözüm şudur:

Responder sertifikası self-signed ise vCenter trusted CA store’a ekleyelim.

Mantık doğru gibi görünür ama pratikte vCenter bunu reddedebilir. Çünkü:

• Self-signed sertifika “CA gibi” davranacak şekilde üretilmediyse
• (ör: Basic Constraints: CA:TRUE yoksa)
• vCenter bunu CA store’a kabul etmeyebilir

Yani sertifika her ne kadar “güvenilmesi gereken” bir sertifika olsa da, “CA sertifikası” formatında olmadığı için vCenter UI’sinden istenen şekilde tanıtılamaz.

Kritik bilgi: vSphere UI, responder signing certificate’ı seçtirmez

Bu kısım çok önemli:

• OCSP kontrolünü vSphere UI’dan açabilirsiniz
• OCSP URL tanımlayabilirsiniz
• Ama “şu signing sertifikasını kullan/güven” diyemezsiniz

Yani GUI tarafı eksik kalıyor.

Çözüm:

sso-config.sh ile CLI üzerinden alternate OCSP responder eklemek ve signing sertifikasını özellikle belirtmek.

Çözüm: CLI ile alternate OCSP responder eklemek

Aşağıdaki işlemler vCenter üzerinde doğrudan yapılır. SSH ile giriş yapmanız gerekir.

Not: -t parametresi SSO tenant/domain bilgisidir. Genellikle:
vsphere.local

1) OCSP revocation checking’i aktif et

sso-config.sh -set_authn_policy -t vsphere.local -useOcsp true

Bu komut vCenter SSO tarafında OCSP kontrolünü devreye alır.

2) OCSP Responder’ı alternate olarak ekle + signing cert belirt

Bu komut 3 kritik bilgi ister:

• Tenant: -t vsphere.local
• OCSP URL: -ocspUrl ...
• Signing certificate: -ocspSigningCert ...

Örnek:

sso-config.sh -t vsphere.local -add_alt_ocsp \
  -ocspUrl http://ocsp.kadirkozan.local \
  -ocspSigningCert ocsp-signing-cert.cer

Çok önemli not:
Eğer ortamda Enhanced Linked Mode (ELM) varsa bu ayar diğer vCenter’lara replike olur. Yani “tek tek her vCenter’da” yapmak gerekmez.

3) Yapılandırmayı doğrula

sso-config.sh -t vsphere.local -get_alt_ocsp

Bu komut tanımlı alternate OCSP responder listesini döndürür.
Çıktıda URL ve sertifika ilişkisini görmelisiniz.

4) Alternate responder’ları silme

sso-config.sh -t vsphere.local -delete_alt_ocsp

Uyarı: Bu komut tüm alternate OCSP tanımlarını kaldırır. Eğer birden fazla responder/backup tanımlıysa yeniden eklemeniz gerekir.

OCSP responder sertifikası elinde yoksa: OpenSSL ile çıkarma

En pratik kısım burasıdır.

Responder sertifikasını almak için illa PKI ekibinden beklemek zorunda değilsiniz. OCSP response içinde imzalayan sertifika bulunduğu için openssl ocsp ile yakalanabilir.

1) Temel openssl ocsp sorgusu

openssl ocsp -issuer issuer_cert.cer \
  -cert cert_to_check.cer \
  -url http://ocsp.kadirkozan.local \
  -resp_text

Burada hedef “valid response almak” değil, “response üretmek”.

Bu yüzden gerçek issuer/cert bile gerekmeyebilir.

Örnek:

openssl ocsp -issuer DODIDCA_62.cer \
  -cert dummy.cer \
  -url http://ocsp.kadirkozan.local \
  -resp_text

2) Çıktıdan sertifikayı ayıkla

Komut çıktısının alt tarafında şu blok çıkar:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Bu bloğu bir dosyaya kaydedin:

vi ocsp-signing-cert.cer

Sonra yukarıdaki sso-config.sh -add_alt_ocsp komutunda bu dosyayı kullanın.

9) vCenter’da OCSP / Smart Card / SSO ile ilgili Log Path’leri ve Grep Komutları

OCSP yapılandırması sonrası giriş hatası aldığında, en hızlı ve doğru teşhis yöntemi log okumaktır. vCenter Appliance (VCSA) üzerinde en kritik loglar şuralardadır:

9.1 SSO / WebSSO Logları (Smart Card login hataları burada görünür)

📌 Log path

/var/log/vmware/sso/ssoAdminServer.log
/var/log/vmware/sso/sso-websso.log
/var/log/vmware/sso/sso-ui.log

Genelde Smart Card ve OCSP ilgili asıl hata sso-websso.log içinde bulunur.

🔎 OCSP ile ilgili hızlı grep örnekleri

1) OCSP, responder, revocation kelimeleri

grep -iE "ocsp|responder|revocation|crl" /var/log/vmware/sso/sso-websso.log

2) CertPath / Trust / Validation hataları

grep -iE "CertPath|Validator|validate certificate path|PKIX|trust" /var/log/vmware/sso/sso-websso.log

3) Smart Card login attempt araması

grep -iE "smart|card|x509|certificate|authn" /var/log/vmware/sso/sso-websso.log

4) “Responder’s certificate…” hatasının birebir avı

grep -i "Responder's certificate" /var/log/vmware/sso/sso-websso.log

vCenter Authentication / Identity Provider logları

Path

/var/log/vmware/vsphere-ui/logs/
/var/log/vmware/vpxd/

Örnek grep

grep -iE "ocsp|certificate|revocation" /var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log

Genel sistem logları (network/DNS/SSL etkileri)

OCSP responder erişilemiyorsa ya da DNS çözemiyorsa loglarda ipucu bulunur.

/var/log/messages
/var/log/syslog

Örnek:

grep -iE "ocsp|dns|ssl|certificate|x509" /var/log/messages

OCSP Response Test Komutları (vCenter Üzerinden “Gerçekten Çalışıyor mu?” Testi)

OCSP tarafında hata olduğunda 2 tip problem görülür:

1. Network erişim problemi (responder’a bağlanamıyor)
2. Kripto / trust problemi (responder cevap dönüyor ama doğrulanamıyor)

Bu ayrımı iyi yapmak gerekir.

Network kontrolü (OCSP URL erişilebilir mi?)

Curl ile hızlı test

curl -I http://ocsp.kadirkozan.local

Bazı OCSP sunucuları “HTTP 200 dönmez” ama bağlantı kurulması bile yeterli bir testtir.

TCP port kontrolü

nc -vz ocsp.kadirkozan.local 80

HTTPS OCSP kullanıyorsan (ör: 443):

nc -vz ocsp.kadirkozan.local 443

OpenSSL ile OCSP response üretip responder sertifikasını görmek

En pratik “response dönüyor mu?” testi:

openssl ocsp -issuer issuer_cert.cer \
  -cert cert_to_check.cer \
  -url http://ocsp.kadirkozan.local \
  -resp_text

Önemli çıktılar

• OCSP Response Status: successful (0x0) → responder çalışıyor
• aşağıda -----BEGIN CERTIFICATE----- bloğu → signer cert yakalanabilir

OCSP response doğrulama (ileri seviye)

Responder sertifikasını dosyaya yazdıktan sonra:

openssl ocsp -issuer issuer_cert.cer \
  -cert cert_to_check.cer \
  -url http://ocsp.kadirkozan.local \
  -VAfile ocsp-signing-cert.cer \
  -resp_text

Buradaki amaç: responder’ın imzası doğrulanabiliyor mu?

“Self-signed certificate verify error” ne demek?

Şu hatayı görebilirsin:

Verify error: self-signed certificate

Bu şunu gösterir:

• Responder cevap dönüyor
• Signing cert response içinde var
• Sertifika zinciri güvenilir değil / CA store yok

İşte vCenter tarafındaki problem de zaten buradaki “trust” tarafıdır.

Enhanced Linked Mode (ELM) Ortamlarında Replikasyon Doğrulaması

Makaledeki en kritik operasyonel bilgilerden biri şu:

sso-config.sh ile yapılan Alternate OCSP tanımı ELM’de diğer vCenter’lara replike olur.

Ama “replike oldu mu?” sorusunu doğrulamak şart.

ELM node’larında Alternate OCSP kontrolü

Her vCenter node’unda (en az 2 node) şu komutu çalıştır:

sso-config.sh -t vsphere.local -get_alt_ocsp

Beklenen:

• URL aynı görünmeli
• signing cert tanımı aynı görünmeli

Eğer Node-1’de var Node-2’de yoksa:

• replikasyon gecikmiş olabilir
• STS/SSO replication sorunu olabilir
• node ELM’den kopmuş olabilir

SSO replication health kontrol ipuçları

ELM sorunlarında çoğu zaman şunlar görülür:

• Token/STS hataları
• IDMD replikasyon problemleri
• domain join / PSC/SSO uyumsuzluğu

İpucu grep:

grep -iE "replication|partner|psc|sts|token" /var/log/vmware/sso/ssoAdminServer.log

Benzer Hata Senaryoları ile Kıyas Bölümü (SSO/PKI Mantığını Oturtma)

Burada çok faydalı bir “akıl yürütme” analojisi var.

Senin daha önce sorduğun storage uyarısı şuna benziyordu:

Snapshot reserved capacity threshold exceeded
ve iki seçenek:
– purge snapshot (en eskileri sil)
– reject writes (yazma işlemlerini fail et)

Bu yaklaşımı SSO/PKI dünyasına uyarlarsak:

“Reject Writes” benzeri SSO/PKI davranışı nedir?

OCSP doğrulaması devredeyken vCenter şunu yapar:

• Sertifikayı doğrular
• İptal durumunu mutlaka kontrol eder
• Eğer OCSP status’u “bilinmiyor / doğrulanamıyor” ise…

vCenter çoğu senaryoda güvenlik sebebiyle şu şekilde davranır:

Fail closed → yani “güvenemiyorsam içeri alma”

Bu tam olarak storage’daki “Reject writes” mantığıdır.

• Güvenlik korunur
• yanlış yapılandırmada herkes login olamaz

“Purge” benzeri SSO/PKI davranışı nedir?

Bazı sistemlerde (ve bazı policy’lerde) revocation check yapılamadığında şöyle bir davranış olabilir:

“OCSP unreachable olsa da login olsun”
(fail open)

Bu da snapshot purge mantığına benzer:

• sistem çalışmaya devam eder
• ama güvenlik/denetim riski oluşabilir

OCSP tarafında görülen benzer hata tipleri (kıyas tablosu)

A) Responder erişilemiyor (network/DNS)

Belirti:

• login gecikir, timeout
• loglarda “unable to reach OCSP responder”
  Test:

curl -I http://ocsp.kadirkozan.local
nc -vz ocsp.kadirkozan.local 80

B) Responder cevap veriyor ama signer trust yok

Belirti:

• “CertPathValidatorException”
• “certificate is not authorized…”
  Test:

openssl ocsp ... -resp_text

Çözüm:

• sso-config.sh -add_alt_ocsp -ocspSigningCert ...

C) OCSP responder signing cert yanlış / key usage yok

Belirti:

• responder cert EKU’su hatalı
• sign edemez
  Çözüm:
• PKI tarafında doğru “OCSP Signing” sertifikası üretilmeli

D) CA/Chain problemi (Issuer/CA eksik)

Belirti:

• “Unable to validate certificate path”
• “PKIX path building failed”
  Çözüm:
• gerekli CA chain vCenter trust store’a eklenmeli

Sahada Pratik Kullanım: Troubleshooting Akışı (Check-list)

Sahada en hızlı çözüm akışı:

1. OCSP URL reachable mi? curl -I http://ocsp.kadirkozan.local nc -vz ocsp.kadirkozan.local 80
2. OCSP response dönüyor mu? openssl ocsp -issuer dummy.cer -cert dummy.cer -url http://ocsp.kadirkozan.local -resp_text
3. Responder signing cert’i response’tan çıkar
   • BEGIN CERTIFICATE bloğunu al
   • ocsp-signing-cert.cer yap
4. vCenter’a alternate OCSP + signing cert tanıt sso-config.sh -t vsphere.local -add_alt_ocsp -ocspUrl http://ocsp.kadirkozan.local -ocspSigningCert ocsp-signing-cert.cer
5. ELM varsa diğer node’larda doğrula sso-config.sh -t vsphere.local -get_alt_ocsp
6. Log ile doğrula grep -iE "ocsp|responder|CertPath|validate certificate path" /var/log/vmware/sso/sso-websso.log