Besoin d'aide mise en place d'une chaîne d'autorité de truststore (dans Tomcat)

Question

Le plomb dans ... Je ne suis pas un expert, de loin, dans la sécurité des applications via SSL, mais je suis en train d'établir un environnement de test qui comprend tous les scénarios possibles que nous pouvons rencontrer dans la production. Pour cela, j'ai un arbre des autorités de certification (CA) qui sont les émetteurs d'un assortiment de certificats de client de test et noeud / certificats de serveur (environnement de test complexe représentant les différents services Web publiés et d'autres applications que nous intégrons avec).

La structure de ces CA sont les suivantes: Root CA, qui a signé / publié sous CA1, Sous CA2, et sous CA3. Ces sous-marins ont ensuite signé / émis tous les certificats de ces différents nœuds et clients dans l'environnement.

Maintenant, pour la question .... Dans le truststore ma demande, je voudrais tout confiance signé par Sous CA1, et sous CA2, mais pas sous CA3 (non fiable). Est-ce que cela veut dire mon truststore doit (1) ne comprennent que sous CA1 et sous CA2, ou (2) devrait-il inclure Root CA, Sous CA1, et sous CA2?

Je ne sais pas quelle est la bonne façon de représenter cette chaîne de confiance dans un truststore. À l'avenir, je voudrais également ajouter un sous CA4 (signé / délivré par l'autorité de certification racine), mais l'ajouter à une liste de révocation de certificats (CRL de) à des fins de test.

À l'avance, merci pour toute aide à ce sujet. Il est très apprécié.

Answer 1

OPPOSITION: Je ne vais pas tester ce donc j'espère que ma réponse est correcte.

Je pense que votre hypothèse de base est correcte. Je ne crois pas que vous pouvez sélectivement Révoquer la confiance sans écrire de code personnalisé, de sorte que votre truststore ne doit contenir que des certificats qui sont entièrement confiance. Alors, laissez l'autorité de certification racine et de choisir votre option (1).

Comme vous pouvez le voir, en essayant d'appliquer le contrôle d'accès tels à grain fin est mal adapté à la Java (et plus tous les autres du système) certificat X509 modèle d'authentification basé. Ils sont essentiellement conçus pour sous-traiter la vérification d'identité à Verisign, Thawte, GoDaddy, GlobalSign, etc. pour les certificats SSL et des certificats de signature de code. Il peut prendre en charge d'autres modèles, y compris les certificats auto-signés, mais non sans douleur initiaux considérables et des maux de tête d'entretien en cours.