gestione avanzata certification authority variabili
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.
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.
- ZeroUno
- Staff
- Messaggi: 5441
- 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
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
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
- targzeta
- Iper Master
- Messaggi: 6631
- 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
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
Emanuele
Non capisco le domande, se firmi con D perché dovresti mettere CA3? Ma forse non ho proprio capito il discorso
Emanuele
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
- ZeroUno
- Staff
- Messaggi: 5441
- 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
io sono sistemista(sti stistemisti!)
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
- targzeta
- Iper Master
- Messaggi: 6631
- 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
E non me lo ero dimenticato !
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: Nota che CA1/CA2/CA3 sono la stessa certification authority, stesso commonname, stessa chiave privata, stesso modulus.
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: 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.
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 catenaZeroUno 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.
Emanuele
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
- ZeroUno
- Staff
- Messaggi: 5441
- 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
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