Pagina 1 di 5 1 2 3 ... ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 43
  1. #1

    Tool per la creazione di un certificato client

    Ciao a tutti,

    sono un programmatore .NET e sto creando un clientino JAVA che deve interfacciarsi con un WCF Service in modalità TWO WAY SSL: la parte server è gia certificata, qualcuno saprebbeindicarmi come creare un certificato per il client JAVA e se esistono tools a tal proposito?

    Grazie

    Mike "The Ram"

  2. #2
    Utente di HTML.it
    Registrato dal
    Sep 2012
    Messaggi
    707
    Non conosco questi WCF Service ma conosco i certificati, sarà un X.509. Il server l'hai fatto tu o è sotto il tuo controllo? Perché comunque il certificato client andrà fatto firmare dalla CA sul server ovviamente per essere valido.

    Prova a guardare qui:
    http://www.codeproject.com/Articles/...h-Certificates

  3. #3
    Ciao,

    se hai installato netbeans + glassfish (...forse servono anche le librerie Metro)
    è probabile che tu abbia già i trustore/keystore java (... i file jks)
    in una cartella tipo : C:\Program Files\glassfish-3.1.2\glassfish\domains\domain1\config.
    EDIT :
    se ricordo bene la password dovrebbe essere changeit

    Poi potresti usare keytoolUI per estrarti i certificati ( ... dovresti avere xws_security_client e xws_security_server) e la relativa CA da importare nello store dei certificati di windows.

    Per crearti i certificati di test potresti usare anche questo:
    http://msdn.microsoft.com/en-us/library/ms733813.aspx
    e sempre keytoolUI per crearti i trustore/keystore java.


    HTH


    P.S.
    ... anche se è una possibilità remota,in ogni caso verifica che i certificati
    abbiano il Subject Key Identifier altrimenti con WCF non ti funzioneranno.

  4. #4
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    ragazzi non facciamo confusione:
    il certificato può essere firmato da CHIUNQUE, bisogna invece che il server abbia nel suo truststore (inteso come repository dei certificati) il certificato del firmatario, o meglio la catena dei certificati "firmatari" che presenta il client.

    Scenario:

    Client genera certificato, trusta CA1, a sua volta trustata da CA2, a sua volta trustata da CA3.
    A seconda delle impostazioni del server, Client è accettato se ha CA1, CA2, CA3 oppure CA1 e CA2, oppure CA1 solo.

    Ora quello che serve a lui è un modo per generare questi certificati da utilizzare per le connessioni.
    Dipende da cosa ha installato nella macchina, in ambiente .NET non saprei, in ambiente java può utilizzare (senza passare per netbeans) il comando keytool (a tal proposito leggi qui )

    Keytool è un comando che si trova nella cartella bin del JDK (non ti basta solo l'ambiente di esecuzione).

    Altro strumento validissimo, ostico da usare, che preferisco è openssl.

    Altrimenti, se hai tempo e voglia, guarda le librerie di bouncycastle (ci sono anche per .NET) e scrivi tu una tua piccola applicazione che crei la richiesta di certificato.
    Ricorda che devi far firmare questa richiesta da una CA.
    RTFM Read That F*** Manual!!!

  5. #5
    Utente di HTML.it
    Registrato dal
    Sep 2012
    Messaggi
    707
    il certificato può essere firmato da CHIUNQUE,
    Questo no, la firma di un certificato può farla SOLO chi ti vuole poi riconoscere il certificato altrimenti che sicurezza avrebbe?

    La "firma" si fa con la chiave PRIVATA non con la chiave pubblica. La chiave pubblica serve invece a verificare se quella firma è autentica, cioé è stata fatta dalla corrispettiva chiave privata. Questo è il meccanismo.

    Puoi trovarlo per esempio qui: http://en.wikipedia.org/wiki/Digital_signature
    "A signing algorithm that, given a message and a private key, produces a signature."

  6. #6
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    Originariamente inviato da c0der
    Questo no, la firma di un certificato può farla SOLO chi ti vuole poi riconoscere il certificato altrimenti che sicurezza avrebbe?

    La "firma" si fa con la chiave PRIVATA non con la chiave pubblica. La chiave pubblica serve invece a verificare se quella firma è autentica, cioé è stata fatta dalla corrispettiva chiave privata. Questo è il meccanismo.

    Puoi trovarlo per esempio qui: http://en.wikipedia.org/wiki/Digital_signature
    "A signing algorithm that, given a message and a private key, produces a signature."
    Posso produrre io stessa una coppia di chiavi asimmetriche e usare la chiave privata per firmare una certificate request fatta da me. Di fatto ho creato un certificato particolare chiamato "self-signed", in cui "io me la canto e io me la suono" detta in parole povere.

    Tu c0der puoi decidere che io sia una persona affidabile e accettare il mio certificato (operazione fatta di solito inserendo il certificato all'interno del tuo truststore), ma puoi benissimo decidere che io non lo sia e di fatto rifiutarmi.
    Chiunque può firmare una richiesta di certificato (basta la coppia di chiavi asimmetriche), devi vedere poi se si fidano del firmatario oppure no.
    Di solito, quando si deve usare il certificato in produzione, si crea una richiesta di certificato, la si invia ad enti certificatori (il primo che mi viene in mente è verisign) e questo se ritiene che siamo attendibili, ci restituisce la richiesta (che non è più richiesta ma certificato a tutti gli effetti).
    Quando si usa il certificato in connessioni, l'identità viene accettata perché ci si fida di chi ha apposto la firma (cioè di Verisign).
    Ci possono essere altri enti certificatori (che attestano l'identità del firmatario), fino a risalire a quello che viene definito certificato di root, per forza di cose un self-signed.
    Se tutti i certificati, da quello utente al root, sono trustati, il certificato è valido.

    Il protocollo di validazione prevede che su una catena di certificati di ad esempio 20 certificati, se il 20 non è trustato, il certificato è invalido.
    Nelle applicazioni spesso si deroga questo principio (ammettendo che almeno sia valido quello del firmatario).

    Continuo, o ti basta per certificare la mia conoscenza in campo di sicurezza informatica (visto che è il mio pane quotidiano?)
    RTFM Read That F*** Manual!!!

  7. #7
    Utente di HTML.it
    Registrato dal
    Sep 2012
    Messaggi
    707
    È un argomento che conosco come le mie tasche figurati.
    Stiamo parlando di un server che autenticherà il client se vedrà che il certificato l'ha firmato LUI! Come puoi pensare che possa firmarlo qualcun altro? O che sia self-signed.... allora chiunque potrebbe accedere al server..

    Tutto il discorso che hai scritto su verisign serve per ottenere un certificato per un server, di modo che i client possano essere sicuri che il server sia fidato (il suo certificato ha la firma di verisign, e con la chiave pubblica di verisign posso verificarlo). Ma qui si sta parlando di certificati client usati per l'autenticazione con uno specifico server (WCF Service - TWO WAY SSL). In questi casi è quel server che firma i certificati in modo che solo lui ha il controllo di chi si potrà mai connettere al servizio. Non si usa nè la firma di terzi nè la self-signed, ma la propria.

  8. #8
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    Originariamente inviato da c0der
    È un argomento che conosco come le mie tasche figurati.
    Stiamo parlando di un server che autenticherà il client se vedrà che il certificato l'ha firmato LUI! Come puoi pensare che possa firmarlo qualcun altro? O che sia self-signed.... allora chiunque potrebbe accedere al server..

    Tutto il discorso che hai scritto su verisign serve per ottenere un certificato per un server, di modo che i client possano essere sicuri che il server sia fidato (il suo certificato ha la firma di verisign, e con la chiave pubblica di verisign posso verificarlo). Ma qui si sta parlando di certificati client usati per l'autenticazione con uno specifico server (WCF Service - TWO WAY SSL). In questi casi è quel server che firma i certificati in modo che solo lui ha il controllo di chi si potrà mai connettere al servizio. Non si usa nè la firma di terzi nè la self-signed, ma la propria.
    hai mai implementato un server SSL?
    Può essere il server a firmare il certificato, ma se il server non ha nel suo truststore l'identità del firmatario, col cavolo che ti autorizza!!!!

    Lato client deve generare una richiesta di certificato, farlo firmare e assicurarsi che il server trusti il suo firmatario.
    Se il server decide di trustare gli autofirmati, saranno falle di sicurezza loro, ma ci sarà qualcuno a manina a configurare il server e a dire accetto gli autofirmati.
    Il client deve dire: accetto il server, per poterlo verificare deve contenere le sue info nel suo truststore, in modo da poterne verificare l'identità.

    Lato server il discorso è identico.
    Si chiama TWO WAY SSL perché prevede l'autenticazione sia lato client che lato server.
    RTFM Read That F*** Manual!!!

  9. #9
    Utente di HTML.it
    Registrato dal
    Sep 2012
    Messaggi
    707
    Ho implementato un mucchio di software in C con libopenssl, PKCS7 e PKCS10 e installato CA.

    Comunque se non ti fidi di me chiedi a chiunque o leggi il primo weblink che ho postato (Section 3: Create a Client Certificate, è il server che crea i certificati per i client).

  10. #10
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    Originariamente inviato da c0der
    Ho implementato un mucchio di software in C con libopenssl, PKCS7 e PKCS10 e installato CA.

    Comunque se non ti fidi di me chiedi a chiunque o leggi il primo weblink che ho postato.
    tutto questo non c'entra con il setup di un server ssl (e anche del client in questo caso) come non c'entra il tuo link (visto che parla solo di definizione di certificato).

    stackoverflow al solito è ben fatto
    RTFM Read That F*** Manual!!!

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.