gestione avanzata certification authority variabili

Postate qui per tutte le discussioni legate alla sicurezza di Linux/Slackware

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute.
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5385
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

gestione avanzata certification authority variabili

Messaggio da ZeroUno »

E' talmente complesso l'argomento che non sapevo nemmeno che titolo mettere.

In pratica.

Una Certification Authority ha l'abitudine di rigenerare periodicamente il proprio certificato, mantenendo common name e chiave privata, cambiando data di scadenza e attributi del certificato (nel caso specifico i constraints, cosa voluta dalla rootca).
La CA genera certificati di firma

ora diciamo che nel tempo i certificati della ca siano CA1.pem CA2.pem CA3.pem, e diciamo che nel tempo le ca hanno firmato un po' di chiavi con questi common name:
CA1 -> A B
CA2 -> C D
CA3 -> E F
tutti di durata triennale.

L'authority avverte tutti gli attori quando cambia il certificato della CA.

diciamo che io sono l'owner del certificato D ed ho anche una applicazione con cui validare i documenti firmati da tutti.

prima domanda: quando firmo un documento nella catena di certificazione ci devo mettere la CA2 o la CA3? sia lato tecnico per validazione (openssl me la valida con qualunque delle 3; le applicazioni sono eterogenee ma credo tutte java based ma non ci posso fare affidamento, non ne ho il controllo se non della mia) sia lato legale.
seconda domanda: se nel keystore c'è la rootCA e la sola CA3, può validare documenti firmati da B, quindi generati da CA1, e che per qualche motivo mette nella catena di certificazione CA2?
per qualche motivo la mia applicazione ha difficoltà a selezionare la corretta CA da mettere nella catena di certificazione se metto tutte e 3 le CA nel keystore (p.s. non intendiamo keystore come jks di java ma come entità astratta a causa della natura dell'applicazione, quindi riflessione valide a livello di protocollo di certificazione/rfc)

L'authority mi ha fatto un richiamo perchè firmavo mettendo ancora CA2 nella catena, visto che con quella era stato generato il certificato. Ad oggi ho lasciato nello store solo CA3, ma ad oggi non ho modo di verificare se gli altri attori (numero ristretto) mettono la CA3 o una delle precedenti nella catena di certificazione. Immagino la CA3 in quanto se hanno fatto richiamo a me lo avranno fatto anche agli altri se mettevano CA1 o CA2. Ma quello che è certo è che quando viene generata una CA4 per un periodo alcuni firmeranno con CA3 in catena alcuni con CA4.

La mia impressione è che la rootCA voglia mettere CA1 e CA2 in revocation list, anche se A,B,C,D sono in corso di validità.

Io noto un po' di bug in questa gestione:
1) se nella catena ci metto D+CA3 sicuramente c'è l'incongruenza che l'inizio di validità del certificato di D è precedente all'inizio di validità della CA; non escludo altre incongruenze
2) se nella catena ci metto D+CA2 potrebbe venire l'incongruenza che CA2 potrebbe essere revocata.

A questo punto quale è la strada corretta?


Scusate se è un po' contorto, ma lo è l'argomento

grazie
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6589
Iscritto il: gio 3 nov 2005, 14:05
Nome Cognome: Emanuele Tomasi
Slackware: 64-current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: gestione avanzata certification authority variabili

Messaggio da targzeta »

Se CA emette il certificato CA1 e poi CA1 firma i certificati A e B, allora quando firmi un documento con A o B potresti anche lasciare solo quelli (dico A o B). Il problema è che chi fa la verifica potrebbe non avere il certificato CA1 e quindi non riesce a risalire la catena. Così si possono anche mettere i certificati intermedi. Quindi firmando con A ci metto A e CA1, in questo modo la catena è risolta (perchè CA immagino sia una root o comunque è presente sul sistema che verifica). Con Java ho avuto alcuni problemi a volte perché mi sa che una un file tutto suo o qualcosa del genere, i sistemisti non mi hanno mai saputo spiegare bene la faccenda (sti stistemisti!).

Non capisco le domande, se firmi con D perché dovresti mettere CA3? Ma forse non ho proprio capito il discorso :D

Emanuele
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5385
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: gestione avanzata certification authority variabili

Messaggio da ZeroUno »

(sti stistemisti!)
io sono sistemista :D

Nota che CA1/CA2/CA3 sono la stessa certification authority, stesso commonname, stessa chiave privata, stesso modulus.

Non posso dare per presupposto che l'applicazione di verifica conosca la ca intermedia (ovvero CA1/CA2/CA3); con certezza conosce la rootCA.
Tra l'altro quando faccio server https ho imparato a mettere sempre la ca intermedia perchè a qualche applicazione potrebbe dare fastidio l'assenza.

java usa di default un keystore $JAVA_HOME/jre/lib/security/cacerts in formato jks di default (ma l'applicazione potrebbe modificare il comportamento) dove sono presenti sicuramente tutte le rootca più facoltativamente le ca intermedie. Chiaramente se la ca intermedia non è né nella catena di certificazione né in questo keystore, la verifica della catena fallisce.

Che se firmo con D devo mettere CA3 me lo ha chiesto l'organo di vigilanza, corretto o no che sia. (che poi per errore per D ci mettevo CA1 per mesi e gli applicativi di tutti non hanno fatto una piega è un'altra storia).
Ha senso perchè la CA comunque è quella, qualunque sia il suo certificato, ed i certificati CA1 e CA2 potrebbero venire revocati dalla rootCA per evitare che con queste vengano firmati nuovi certificati.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6589
Iscritto il: gio 3 nov 2005, 14:05
Nome Cognome: Emanuele Tomasi
Slackware: 64-current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: gestione avanzata certification authority variabili

Messaggio da targzeta »

ZeroUno ha scritto:
mar 24 ago 2021, 11:06
(sti stistemisti!)
io sono sistemista :D
E non me lo ero dimenticato :badgrin:!
ZeroUno ha scritto: Nota che CA1/CA2/CA3 sono la stessa certification authority, stesso commonname, stessa chiave privata, stesso modulus.
Sì, l'avevo capito, però per me rimangono comunque tre certificati differenti (oltre alla scadenza hai detto che ci sono altri campi che differiscono).
ZeroUno ha scritto: Non posso dare per presupposto che l'applicazione di verifica conosca la ca intermedia (ovvero CA1/CA2/CA3); con certezza conosce la rootCA.
Tra l'altro quando faccio server https ho imparato a mettere sempre la ca intermedia perchè a qualche applicazione potrebbe dare fastidio l'assenza.

java usa di default un keystore $JAVA_HOME/jre/lib/security/cacerts in formato jks di default (ma l'applicazione potrebbe modificare il comportamento) dove sono presenti sicuramente tutte le rootca più facoltativamente le ca intermedie. Chiaramente se la ca intermedia non è né nella catena di certificazione né in questo keystore, la verifica della catena fallisce.
E infatti mi sembra corretto. Io ho avuto dei problemi con degli applicativi Java che pur avendo il certificato intermedio installato sulla macchina, non veniva visto dall'applicazione.
ZeroUno ha scritto: Che se firmo con D devo mettere CA3 me lo ha chiesto l'organo di vigilanza, corretto o no che sia. (che poi per errore per D ci mettevo CA1 per mesi e gli applicativi di tutti non hanno fatto una piega è un'altra storia).
Ha senso perchè la CA comunque è quella, qualunque sia il suo certificato, ed i certificati CA1 e CA2 potrebbero venire revocati dalla rootCA per evitare che con queste vengano firmati nuovi certificati.
Per come la so io è corretto così. CA3 ha firmato e rilasciato il certificato D e quindi è solo CA3 che ha senso mettere. Il fatto che pur avendo messo CA1 gli applicativi abbiano continuato a lavorare bene potrebbe anche dipendere dal fatto che gli applicativi avevano comunque il nuovo certificato CA3. Io credo che anche se nella firma ci metti due o più certificati l'applicativo non è detto che gli usi, soprattutto se sono scaduti. Però se non ti hanno mai dato problemi, vuol dire che per loro la catena era certificata, oppure che non hanno mai controllato la catena :lol:

Emanuele
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5385
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: gestione avanzata certification authority variabili

Messaggio da ZeroUno »

D è stato rilasciato da CA2
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Rispondi