Le plus couramment cela est dû à une erreur de configuration de la base de données. Dans le journal du serveur (JBOSS_HOME/server/default/log/server.log) vous verrez probablement quelques erreurs du type SQLException. Vous devrez :
Etudier la section configuration et dépannage dans le document /howto/HOWTO-database.txt.
Vous avez probablement un package préinstallé provenant de Fedora ou de Suse. Ces packages ne contiennent pas tous les modules contenu dans Ant par défaut. Vous avez besoin du “package optionnel” inclus dans la distribution officielle de Ant. Ajouter les modules à la version de ANT déjà installée, ou télécharger la dernière version de Ant de http://ant.apache.org/.
Pour réparer ce problème, il suffit de faire pointer dans /etc/ant.conf la version de Ant installée par l'utilisateur (dans /votre/ant/home). Appliquer la modification suivante :
# # ant.conf (Ant 1.6.x) # JPackage Project (http://www.jpackage.org/) # # Validate --noconfig setting in case being invoked # from pre Ant 1.6.x environment if [ -z "$no_config" ] ; then no_config=true fi # Setup ant configuration if $no_config ; then # Disable RPM layout rpm_mode=false else # Use RPM layout rpm_mode=true # ANT_HOME for rpm layout ANT_HOME=/usr/share/ant fi to this # # ant.conf (Ant 1.6.x) # JPackage Project (http://www.jpackage.org/) # # Validate --noconfig setting in case being invoked # from pre Ant 1.6.x environment if [ -z "$no_config" ] ; then no_config=true fi # Setup ant configuration if $no_config ; then # Disable RPM layout rpm_mode=false else # Use RPM layout rpm_mode=false # ANT_HOME for rpm layout ANT_HOME=/your/ant/home fi
Il y a de la documentation chez JBoss pour gérer les différentes options :
Pour aller au plus simple , il y a deux outils pour vous aider à répondre à votre besoin :
EJBCA ne fait pas confiance au DN que l'utilisateur entre quand il crée la demande PKCS10. La seule manière de vérifier le certificat avec ce que vous présentez dans le pkcs10 est d'écrire la même chose dans l'entité d'extrémité d'EJBCA. PKCS#10 est le format standard pour adresser la clef publique (auto-signé pour fournir la preuve de possession) à une AC (autorité de certification).
JBOSS_HOME/server/default/log/server.log
Copier votre fichier dans le répertoire publicweb/root, compiler et redéployer. Le fichier d'index sera affiché dans http://hostname:8080/ejbca, vous pouvez aussi ajouter un répertoire supplémentaire.
1) Avez-vous importé le bon fichier superadmin.p12 dans votre navigateur ? 2) Vous pourriez avoir à supprimer et importer le certificat d'AC dans le Java trust store:
sudo ant javatruststore
Ou vous pouvez exécuter les commandes manuellement. Vous ne devez pas faire cela si vous utilisez la commande « ant javatruststore ».
bin/ejbca.sh ca getrootcert caname rootca.der -der
keytool -alias EJBCA-CA -delete -trustcacerts -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit
keytool -alias EJBCA-CA -import -trustcacerts -file rootca.der -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit
Redémarrer JBoss après avoir effectué les changements dans le java trust store.
3) Peut-être que la configuration de JBoss/Tomcat n'a pas été faite automatiquement parce que vous exécutez une autre configuration par « defaut » dans JBoss. Le fichier « $JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/server.xml » contient la configuration de Tomcat. La configuration devrait être la suivante, le “serverpwd” est le mot de passe du serveur (httpsserver.password) comme configuré dans ejbca.properties.
<!-- HTTPS Connector requiring client cert on port 8443 -->
<Connector port="8443" address="${jboss.bind.address}"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="true"
keystoreFile="${jboss.server.home.dir}/conf/keystore/keystore.jks"
keystorePass="serverpwd" sslProtocol = "TLS" />
En complément, le fichier '$EJBCA_HOME/p12/tomcat.jks' doit être copié dans dans '$JBOSS_HOME/server/default/conf/keystore/keystore.jks', ou 'default' doit être remplacé par la configuration que vous utilisez.
Soit vous avez indiqué un nom de machine (dans la variable httpsserver.hostname du fichier ejbca.properties) qui ne résout pas la machine où se trouvait EJBCA durant le processus d'installation, soit vous avez modifié le port ou JBoss est en écoute.
La première chose à faire et de vérifier la résolution de nom sur la machine ou est déployé EJBCA. Si vous avez besoin de changer l'URL, utiliser la commande « bin/ejbca.sh setup setbaseurl ».
Tomcat a besoin du certificat d'AC qui a émis le certificat serveur, ce certificat est contenu dans le java truststore. Il est importé durant le processus 'ant install'. Quand vous mettez à jour Java, vous obtenez un nouveau java truststore qui est vide.
Pour résoudre cette anomalie, il faut importer de nouveau le certificat de l'AC dans le fichier JAVA_HOME/jre/lib/security/cacerts, ou copier l'ancien java truststore depuis l'ancien JAVA_HOME. Vous pouvez l'importer manuellement en réalisant un export du certificat de l'AC, de cette manière :
bin/ejbca.sh ca getrootcert caname root.der -der
et l'importer dans le fichier cacerts:
keytool -import -trustcacerts -file root.der -keystore $JAVA_HOME/jre/lib/security/cacerts
Si vous souhaitez utiliser de la crypto. forte et/ou des mots de passe de longueur supérieure à 7 caractères dans les keystores. Vous devez installer le fichier Unlimited Strength Jurisdiction Policy Files' du JDK. Le fichier est accessible sur le site de Sun au même endroit ou vous avez téléchargé le JDK. Des informations complémentaires à propos de JCE sont disponibles sur le site de Sun.
Java 1.5.0
Java 1.4.2
Peut-être que BOSS_HOME/server/default/conf/keystore/tomcat.jks doit être exécutable. Tous les scripts dans le répertoire d'EJBCA_HOME/bin doivent être exécutables, exécuter la commande “chmod u+x *.sh”. Assurez-vous que vous réaliser l'installation d'ejbca avec un qu'utilisateur ayant assez de privilèges pour écrire dans JBOSS_HOME, et dans JAVA_HOME/jre/lib/security/cacerts. De préférence le même utilisateur qui est utilisé pour exécuter le serveur de JBoss.
A : Stopper JBoss. Alternative 1: Si vous souhaiter simplement supprimer une table , ouvrir le ficher JBOSS_HOME\server\default\db\hypersonic\default.script et supprimer la ligne qui crée la table, par exemple pour supprimer la table GLOBALCONFIGURATIONDATA, supprimer les lignes :
CREATE TABLE GLOBALCONFIGURATIONDATA(CONFIGURATIONID VARCHAR NOT NULL,DATA VARBINARY,UNIQUE(CONFIGURATIONID)) CREATE UNIQUE INDEX PK_GLOBALCONFIGURATIONDATA ON GLOBALCONFIGURATIONDATA(CONFIGURATIONID)
Juste pour le plaisir, vous pouvez aussi détruire toutes les lignes commençant avec: INSERT GLOBALCONFIGURATIONDATA…
Alternative 2: Télécharger HsqlDb depuis http://hsqldb.sourceforge.net/. décompresser et dans le répertoire 'bin' exécuter run 'runUtil DatabaseManager'. Dans la fenêtre qui ouvre la connexion à 'HSQL Engine Database In-Memory', sélectionner l'URL 'jdbc:hsqldb:$jboss.home\server\default\db\hypersonic\default' vers le chemin de Jboss, par exemple 'C:\jboss\jboss-3.0.6_tomcat-4.1.18'. Maintenant vous pouvez saisir des commandes SQL, par exemple, saisir 'drop table globalconfigurationdata' et appuyer sur 'Execute'. CEpendant, devez maintenant entrer dans le dossier JBOSS_HOME\server\default\db\hypersonic\default.properties et postillonner le numéro de version correctement, éditer les lignes contenant “version ” pour lire 1.6 (pour JBoss 3.0) au lieu de celui qui est là.
Microsoft à modifier le processus de demande de certificat pour des raisons de sécurité. Regarder dans 'src/publicweb/apply/apply_exp.jsp' pour obtenir plus d'informations.
Votre classe d'objets de LDAP pourrait avoir besoin de quelques champs dans le DN que vous n'avez pas saisi. Par exemple, certains schémas exigent SN dans l'attribut DN.
Le serveur d'application officiel utilisé pour le développement est JBoss. Les contributeurs ont testé qu'Ejbca fonctionné aussi bien avec d'autres serveurs d'applications. La version 3.x d'EJBCA est connue pour fonctionner sur JBoss, Jonas et Weblogic. EJBCA essaye de rester au plus près des spécifications et autant que possible devrait s'exécuter sur n'importe quel serveur d'application conforme EJB2. Des différences sont présentes de toute façon, ce qui implique que vous devez tester EJBCA préalablement sur votre serveur.
EJBCA supporte en théorie toutes les bases de données qui fonctionnent avec les serveurs d'applications. La base de données doit supporter 'long fields', les CRL qui peuvent avoir une grande taille. EJBCA est connu pour fonctionner avec MySQL, PostgreSQL 7 et 8, Oracle 8 et 9, Sybase, HypersonicSQL, SAPDB and MSSQL 2000. D'autres bases de données devraient fonctionner avec une adaptation simple des fichiers XML de configuration.
En utilisant le LocalAuthenticationSession (par défaut) tous les utilisateurs ont un STATUT. le statut du cycle de vie commence à New (Nouveau) et fini à Revoked (Revoqué). Seulement quand le statut est à NEW (Nouveau), FAILED (échoué) ou INPROCESS (en cours), il est possible de délivrer un certificat à un utilisateur. Après qu'un certificat ait été délivré, le statut est positionné à GENERATED (généré). Cela fonctionne selon un schéma 'one-time-password' (OTP - mot de passe à usage unique). Pour délivrer un nouveau certificat à l'utilisateur, son statut doit être réinitialisé soit à New (Nouveau), FAILED (échoué) ou INPROCESS (en cours). Cela peut être fait avec l'interface d'administration ou avec la commande suivante:
bin/ejbca.sh ra setuserstatus username status
le statut “10” est égal à New (Nouveau). Pour consulter la liste complète des statuts, taper la commande suivante
'bin/ejbca.sh ra setuserstatus'
EJBCA utilise le format PKCS12 pour le keystore parce que c'est un standard, et nous nous aimons les standards. Normalement keytool (voir Sun) peut lire les fichiers PKCS12 mais ne peut pas écrire, donc BouncyCastle JCE est nécessaire pour manipuler les fichiers PKCS12. Indiquer le fournisseur “jce-jdk14-version.jar” de BouncyCastle dans “jre/bibliothèque/ext”, le classpath par défaut pour les extensions dans Java. Maintenant il devrait être possible de l'exécuter:
keytool -list -alias privateKey -keystore server.p12 -storetype PKCS12 -storepass foo123 -provider org.bouncycastle.jce.provider.BouncyCastleProvider
# Pour commencer générez un nouveau keystore et une paire de clés: keytool -genkey -alias mykey -keystore myks.jks -keyalg RSA -dname c=SE,O=AnaTom,CN=Test -keypass foo123 -storepass foo123 # Votre keystore Sun et maintenant dans le fichier 'myks.jks'. # générer une requête de certificat (PKCS10): keytool -certreq -alias mykey -sigalg SHA1WithRSA -file myreq.p10 -keypass foo123 -keystore myks.jks -storepass foo123
Vous avez maintenant la demande de certificat dans le fichier “myreq.p10”. Ouvrir la page de demande d'EJBCA dans votre navigateur préféré, 'http://127.0.0.1:8080/apply/index.html', et choisir le lien pour les demandes manuelles http://127.0.0.1:8080/apply/apply_man.jsp', 'télécharger le certificat de l'AC racine en cliquant sur le lien. Sauvegarder le certificat en tant que « ca.pem ». Saisir l'identifiant et le mot de passe d'un utilisateur valide avec le statut New (Nouveau), voir la question « pourquoi j'obtiens l'exception/erreur : » en haut. Copier et coller le contenu de la demande de certificat, « myreq.p10 » dans la boîte de texte. sauvegarder le certificat retourné en tant que « cert.pem ».
# Importer certificat racine de l'AC dans le keystore 'myks.jks': keytool -import -alias cacert -file ca.pem -keystore myks.jks -storepass foo123 # Importer le certificat d'entité dans le keystore: keytool -import -alias mykey -file cert.pem -keystore myks.jks -storepass foo123 -keypass foo123 # Maintenant vous pouvez consulter le contenu de votre keystore Sun avec la commande : keytool -list -keystore myks.jks
En théorie, vous pouvez utiliser la même méthode avec un keystore PKCS12 de BouncyCastle en ajoutant les arguments suivants à chaque commande ci-dessus :
-provider org.bouncycastle.jce.provider.BouncyCastleProvider/ -storetype PKCS12
Cependant à l'heure actuelle, une anomalie dans le keytool l'empêche de fonctionner correctement.Je recommande donc d'utiliser 'bin/ejbca.sh ca' pour créer les keystores PKCS12. Il peut être utilisé pour créer toutes sortes de keystores, pas simplement pour les ACs.
Le keystore EJBCA utilise une keystore PKCS12. La clef privée et le certificat d'AC sont contenus dans l'alias 'privateKey'. Si l'AC n'est une AC racine, c.-à-d.. le certificat dans l'alias 'privateKey' est signé par un autre certificat, alors le certificat d'AC (certificat racine) est contenu dans l'alias avec le même nom que le CN de l'AC racine, c.-à-d. le CN de l'émetteur du certificat dans 'privateKey'.
Vous avez indiqué un DN de sujet pour lequel aucun certificat n'a été délivré.
Non, parce que seul BouncyCastle contient les classes pour produire réellement des certificats et de CRLs. JCE permet seulement l'usage, pas la création.