... sembra che tutti lo sapessero tranne me.
Se invece non siete tra i piu' informati, vi racconto che:
presso un cliente, ci siamo imbattuti in un errore di mancata
autenticazione (https) tra un client (Windows, e va beh!) ed uno dei
server web.
I client che sono soggetti a questo errore (al momento non riusciamo
ad avere un errore sistematico, ma "solo" saltuario), dichiarano che
il certificato della intermediate-CA risulta scaduto.
Insomma per farla breve (se qualcuno vuole i dettagli mi contatti direttamente):
- la subCA "VeriSign International Server CA - Class 3", che viene
utilizzata per firmare certificati server, ha in giro almeno 3
certificati diversi, che hanno la stessa chiave pubblica
(cio' vi sconvolge o per voi e' notizia datata ?)
I tre certificati sono diversi in quanto le date di scadenza sono
diverse: 2004, 2011 e 2016; in compenso sono diversi i seriali
(almeno loro) e naturalmente sono diverse le firme digitali dei
certificati stessi.
A seconda delle configurazioni dei client utilizzati, alcune sessioni
di autenticazione rintracciano -localmente o in rete- uno o l'altro di
questi X.509; tutti e tre possono verificare la firma del certificato
server, ma uno dei tre risulta scaduto (nel 2004) ed in quel caso
client non completa l'handshake o in alcuni casi l'utente deve operare
per accettare il warning e superare l'impasse: comunque non il
massimo.
Guardando la rfc5280, mi sembra che sia un obbligo l'inserimento del
DN dell'issuer, ma in questo DN non e' obbligo l'inserimento di
qualche cosa di univoco, come ad esempio il serial del certificato di
verifica.
Considerate anche che il certificato server che stiamo usando, ha
scadenza meta' 2012; quindi superata la data di scadenza del secondo
certificato Verisign (quello 2011) il problema si presentera' piu'
frequentemente (due cert scaduti contro uno ancora valido).
La cosa piu' divertente e' il tool Java di Verisign, che testando il
server web in questione, dichiara che il certificato della
Intermediate CA e' scaduto ! :-) : anche il loro tool seleziona il
certificato meno opportuno.
last but ...
la rootCA "Class 3 Public Primary Certification" (quella che firma i
certificati di subCA) ha un certificato in scadenza il 2 agosto 2028
con algoritmo di firma MD2 / RSA: anche questo forse non proprio il
massimo.
-----------------------
Non voglio entrare nel merito del perche' Verisign (e non e' l'unica,
vedi oltre) combini cose di questo genere; vorrei invece sapere se
qualcuno ha avuto in passato questo tipo di problemi; nel caso:
- si e' fatto ridare i soldi da Verisign (o chi per essa) ? mmmh,
poco probabile.
- ha sostituito tutti i cert server con quelli di una CA piu' affidabile ?
-- eventualmente ha poi ha fatto una campagna di comunicazione (OoB)
per configurare i client con il nuovo rootCA ?
- ha informato i suoi utenti che ... e che quindi ...
btw,
ho poi scoperto che questa estate al DEFCON 18, EFF ha presentato uno
speech interessante proprio sull'argomento dei certificati server e
delle catene di verifica:
www.eff.org / files / DefconSSLiverse.pdf
buona lettura.
S
--
Sandro Fontana
CISSP, ISO27001 L.A., CISM, CISA
http://www.linkedin.com/in/sfontana
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
