Pages : 1
#1 Le 24/06/2014, à 09:32
- pti-jean
[Résolu] pb openssl ca cacert
Bonjour,
Je souhaiterais sécuriser la connexion à un serveur par le protocole ssl en utilisant un certificat cacert.
Bien sur, sur le site d'Ubuntu, il y a un article sur la question, incomplet:
http://doc.ubuntu-fr.org/tutoriel/comme … ificat_ssl
L’article est incomplet, car aujourd'hui pour créer un certificat cacert, c'est pas utile d'aller sur le site de cacert, tout ce passe en ligne de commande, à l'aide de commande du style "openssl ca".
J'ai réussi en partie à créer ce genre de certificat, en suivant ce type de documentation:
http://jeyg.info/des-certificats-signes … c-openssl/
et ce type là:
http://www.site-sans-nom.org/rc2/sysadm … howto.html
Mon problème:
malgré que j'ai configuré les autorités cacert racines dans mon navigateur:
http://www.cacert.org/index.php?id=3
quand je me connecte sur mon serveur certifié cacert, j'ai le message: "Cette connexion n'est pas certifiée"...
Quel est la solution pour ne pas avoir ce message ?
JM
Dernière modification par pti-jean (Le 04/07/2014, à 13:55)
Hors ligne
#2 Le 24/06/2014, à 12:53
- bruno
Re : [Résolu] pb openssl ca cacert
Dans quelle doc ?
Cacert.org est une autorité de certification, par contre leur certificat racine n'est pas installé d'office avec le système et les navigateurs.
Une fois le certificat racine de Cacert.org ajouté il n'y a plus aucun message d'avertissement.
Malheureusement pti-jean ne décrit pas précisément ce qu'il a fait, ni pour quel type de serveur il a besoin d'un certificat.
EDIT : je viens de voir c'est sur la dioc ubuntu-fr.org : c'est faux et d'ailleurs c'est aussi faux de dire que Cacert va générer le certificat. Cacert va simplement signer le certificat que l'utilisateur a généré sur sa machine.
Dernière modification par bruno (Le 24/06/2014, à 12:55)
#3 Le 24/06/2014, à 13:16
- pti-jean
Re : [Résolu] pb openssl ca cacert
Merci Bruno,
Effectivement cacert est bien une autorité de certification...
Exemple d'un site certifié Cacert:
https://effraie.org/
Si on va sur ce site, par défaut il y a le message "Cette connexion n'est pas certifiée"... sauf si on installe les certificats racines cacert sur son navigateur, à partir de cette page:
http://www.cacert.org/index.php?id=3
Il sont là les certificats:
http://www.cacert.org/certs/root.crt
http://www.cacert.org/certs/class3.crt
On peut vérifier, par ce biais que les certificats racines fonctionnent.
Ben pour mon site, dont j'ai créé les certificats à partir des liens cités, j'ai toujours l’avertissement "Cette connexion n'est pas certifiée", alors que je sais très bien que les certificats racines sont correctement installés.
Le type de serveur, c'est un serveur Web Lighttpd en https://monsite.moi:port/
JM
Hors ligne
#4 Le 24/06/2014, à 13:24
- bruno
Re : [Résolu] pb openssl ca cacert
J'ai légèrement retouché la doc ubuntu-fr.org.
Si tu as suivi la procédure, puis copié le contenu de ton fichier csr sur le site cacert.org et enfin récupéré le certificat signé par cacert tout devrait fonctionner.
Il faut aussi bien sûr que l’emplacement de la clé privée et du certificat signé soit renseigné dans la configuration de lighthttpd.
#5 Le 24/06/2014, à 13:41
- pti-jean
Re : [Résolu] pb openssl ca cacert
Ben justement, je ne comprend pas pourquoi on doit passer par le site wet de cacert pour créer ce certificat, alors que cela peut ce faire en ligne de commande ???
J'avais essayé en passant par le site web de cacert, mais j'ai pas d'adresse mail valide dans le domaine que je veux certifier, pour raison technique, et cela semble bloquant, par biais...
Alors qu'en cmd (openssl ca ...), on peut certifier cacert sans adresse mail valide dans le domaine... et même sans compte cacert!
Mais cela résout pas mon problème!
JM
Dernière modification par pti-jean (Le 24/06/2014, à 13:42)
Hors ligne
#6 Le 24/06/2014, à 13:52
- bruno
Re : [Résolu] pb openssl ca cacert
Non !
Soit tu utilises un certificat auto-signé et tu auras toujours un avertissement du navigateur.
Soit tu fais signer ton certificat par une autorité de certification, par exemple cacert.org qui est gratuit. Et dans ce cas, effectivement, il me semble bien qu'il faut fournir une adresse de courriel sur son propre domaine.
Dernière modification par bruno (Le 24/06/2014, à 13:53)
#7 Le 24/06/2014, à 14:12
- pti-jean
Re : [Résolu] pb openssl ca cacert
Il semble que je ne puisse pas techniquement avoir une adresse mail valide dans mon domaine avec un MTA en mode satellite.
Il semble aussi que "openssl ca" créait des certificats signés cacert...
$ man ca
CA(1SSL) OpenSSL CA(1SSL)
NOM
ca - Application minimale d'autorité de certification
SYNOPSIS
openssl ca [-verbose] [-config nom_fichier] [-name section] [-gencrl] [-revoke nom_fichier] [-crl_reason
raison] [-crl_hold instruction] [-crl_compromise moment] [-crl_CA_compromise moment] [-crldays nombre]
[-crlhours nombre] [-crlexts section] [-startdate date] [-enddate date] [-days param] [-md alg] [-policy arg]
[-keyfile nom_fichier] [-key mot_de_passe] [-passin param] [-cert fichier] [-selfsign] [-in nom_fichier] [-out
nom_fichier] [-notext] [-outdir répertoire] [-infiles] [-spkac nom_fichier] [-ss_cert nom_fichier]
[-preserveDN] [-noemailDN] [-batch] [-msie_hack] [-extensions section] [-extfile section] [-engine id] [-subj
param] [-utf8] [-multivalue-rdn]
DESCRIPTION
La commande ca est une application d'autorité de certification (CA pour « Certificate Authority ») minimale.
Elle peut être utilisée pour signer des demandes de certificats sous différentes formes et génère des listes
de révocations de certificats (CRL pour « Certificate Revocation List »). D'autre part, elle maintient une
liste des certificats délivrés et de leur état.
Les descriptions des options sont divisées par type d'action.
OPTIONS POUR LES AUTORITÉS DE CERTIFICATION
-config nom_fichier
Indique le nom du fichier de configuration.
-name section
Indique la section du fichier de configuration à utiliser (remplace default_ca dans la section ca).
-in nom_fichier
Un nom de fichier en entrée contenant une seule demande de certificat à signer par l'autorité de
certification.
-ss_cert nom_fichier
Un seul certificat autosigné à signer par l'autorité de certification.
-spkac nom_fichier
Un fichier contenant une unique clef publique Netscape signée, un défi (challenge) et des données
supplémentaires à signer par l'autorité de certification. Consultez la section FORMAT SPKAC pour des
informations sur le format demandé.
-infiles
Si elle est présente, ce doit être la dernière option. Tous les paramètres suivants sont interprétés comme
des noms de fichiers contenant des demandes de certificat.
-out nom_fichier
Le fichier de sortie où les certificats seront dirigés. Par défaut il s'agit de la sortie standard. Les
détails des certificats y seront également précisés.
-outdir répertoire
Le répertoire qui contiendra les certificats. Les certificats seront écrits vers des fichiers nommés par
le numéro de série en hexadécimal portant le suffixe « .pem ».
-cert
Le fichier de certificat de l'autorité de certification.
-keyfile nom_fichier
La clef privée avec laquelle signer les demandes.
-key mot_de_passe
Le mot de passe utilisé pour chiffrer la clef privée. Sur certains systèmes les paramètres de la ligne de
commande sont visibles (par exemple sous UNIX avec l'utilitaire « ps »), une certaine prudence est donc
nécessaire en utilisant de cette option.
-selfsign
Indique que les certificats émis sont à signer avec la clef utilisée pour signer les demandes de
certificat (donnée avec -keyfile). Les demandes de certificat signées avec une clef différente sont
ignorés. Si -spkac, -ss_cert ou -gencrl sont donnés, -selfsign est ignoré.
Une des conséquences d'utiliser -selfsign est que le certificat autosigné apparaît parmi les entrées de la
base de données de certificats (consultez l'option de configuration database), et utilise le même compteur
de numéro de série que tous les autres certificats signés avec le même certificat autosigné.
-passin param
La source du mot de passe de la clef. Pour plus d'informations sur le format de param, consultez la
section PARAMÈTRES DE PHRASE SECRÈTE d'openssl(1).
-verbose
Affiche des précisions supplémentaires sur les opérations effectuées.
-notext
N'inclut pas la version texte d'un certificat dans le fichier de sortie.
-startdate date
Permet de définir la date de début de validité explicitement. Le format de date utilisé est AAMMJJHHMMSSZ
(comme pour une structure UTCTime ASN1).
-enddate date
Permet de définir la date de fin de validité explicitement. Le format de date utilisé est AAMMJJHHMMSSZ
(comme pour une structure UTCTime ASN1).
-days param
La durée en jour pendant laquelle le certificat sera certifié.
-md alg
Le type de hachage (« digest ») de message à utiliser. md5, sha1 et mdc2 font partie des valeurs
possibles. Cette option s'applique aussi aux listes de révocations de certificats.
-policy param
Cette option définit la « politique » d'autorité de certification à utiliser. Il s'agit d'une section du
fichier de configuration indiquant les champs qui sont obligatoires ou qui doivent correspondre au
certificat de l'autorité de certification. Consultez la section FORMAT DES POLITIQUES pour plus
d'informations.
-msie_hack
C'est une option de compatibilité ascendante pour faire fonctionner ca avec les très vieilles versions du
Certificate Enrollment Control « certenr3 » d'IE. Elle utilise UniversalStrings pour presque tout. Puisque
l'ancien centre de contrôle est victime de plusieurs bogues de sécurité, son utilisation est fortement
déconseillée. Le centre de contrôle plus récent « Xenroll » n'a pas besoin de cette option.
-preserveDN
Normalement, l'ordre des DN d'un certificat est le même que l'ordre des champs dans la section de
politique. Quand l'option est définie, l'ordre est le même que celui de la demande. C'est surtout par
compatibilité avec l'ancien Enrollment Control d'IE qui n'acceptait les certificats que si leurs DN
correspondaient à l'ordre de la demande. Ce n'est plus nécessaire avec Xenroll.
-noemailDN
Le DN d'un certificat peut contenir le champ EMAIL s'il est présent dans le DN de la demande, cependant
c'est une bonne politique de n'avoir que l'adresse électronique configurée dans l'extension altName du
certificat. Quand cette option est définie, le champ EMAIL est retiré de l'objet du certificat et défini
seulement dans les extensions éventuellement présentes. Le mot-clef email_in_dn peut être utilisé dans le
fichier de configuration pour activer ce comportement.
-batch
Active le mode par lot. Aucune question ne sera posée et tous les certificats seront signés
automatiquement.
-extensions section
La section du fichier de configuration contenant les extensions de certificat à ajouter lors de l'émission
d'un certificat (x509_extensions par défaut si l'option -extfile n'est pas utilisée). Si aucune section
n'est présente, un certificat V1 est créé. Si la section d'extensions est présente (même vide), un
certificat V3 est créé. Consultez la page de manuel x509v3_config(5) pour obtenir des précisions sur le
format de section d'extensions.
-extfile fichier
Un fichier de configuration supplémentaire pour y lire les extensions de certificat (en utilisant la
section par défaut si l'option -extensions n'est pas présente).
-engine id
Indique un moteur (en utilisant son identifiant unique id) qui force ca à essayer d'obtenir une référence
fonctionnelle pour le moteur indiqué, et l'initialiser si nécessaire. Le moteur sera ensuite utilisé par
défaut pour tous les algorithmes disponibles.
-subj param
Remplace le nom de sujet donné dans la demande. param doit être formaté comme
/type0=valeur0/type1=valeur1/type2=... où les caractères peuvent être protégées par « \ » (barre oblique
inversée), aucun espace n'est ignoré.
-utf8
Cette option indique que les valeurs des champs doivent être interprétées comme des chaînes UTF-8. Par
défaut, elles sont interprétées comme des chaînes ASCII. Cela signifie que les valeurs des champs,
qu'elles soient demandées sur le terminal ou fournies par le fichier de configuration, doivent être des
chaînes UTF-8 valables.
-multivalue-rdn
Cette option force l'argument de -subj à être interprété avec une prise en charge complète des RDN
multivaleurs. Exemple :
/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=Jean Dupont
Si -multi-rdn est utilisée, alors la valeur de l'UID est 123456+CN=Jean Dupont.
OPTIONS POUR LES LISTES DE RÉVOCATIONS DE CERTIFICATS (CRL)
-gencrl
Cette option génère une liste de révocations de certificats basée sur les renseignements du fichier
d'index.
-crldays nombre
Le nombre de jours avant passage à la liste de révocations de certificats suivante. Ce nombre de jours,
qui est décompté à partir de la date d'exécution, permet de définir la date à placer dans le champ
nextUpdate de la liste de révocations de certificats.
-crlhours nombre
Le nombre d'heures avant passage à la liste de révocations de certificats suivante.
-revoke nom_fichier
Le nom du fichier contenant un certificat à retirer.
-crl_reason raison
La raison du retrait, où la raison vaut : unspecified (« non précisée »), keyCompromise (« clef
compromise »), CACompromise (« autorité de certification compromise »), affiliationChanged (« changement
d'affiliation »), superseded (« remplacé »), cessationOfOperation (« cessation d'activité »),
certificateHold (« certificat suspendu ») ou removeFromCRL (« retiré de la liste de révocations de
certificats »). La casse de la raison n'a pas besoin de correspondre. L'ajout d'une raison au retrait
forcera l'utilisation d'une CRL v2.
En pratique, removeFromCRL n'est pas particulièrement utile parce qu'elle n'est utilisée que pour les
listes de révocations de certificats « delta », qui ne sont pas implémentées pour l'instant.
-crl_hold instruction
Définit le code de raison de révocation d'une liste de révocations de certificats à certificateHold et
l'instruction de suspension à instruction qui doit être un OID. Même si n'importe quel OID peut être
utilisé, seuls holdInstructionNone (dont l'utilisation est déconseillée par la RFC 2459),
holdInstructionCallIssuer ou holdInstructionReject seront normalement utilisés.
-crl_compromise moment
Définit la raison de révocation à keyCompromise et la date de la compromission à moment. moment doit être
au format GeneralizedTime, c'est-à-dire AAAAMMDDHHMMSSZ.
-crl_CA_compromise moment
Il s'agit de la même chose que crl_compromise, mais la raison de la révocation est définie à CACompromise.
-crlexts section
La section du fichier de configuration contenant des extensions CRL à inclure. Si aucune section
d'extension CRL n'est présente, une CRL V1 est créée, sinon une CRL V2 sera créée, même si la section en
question est vide. Les extensions CRL indiquées sont des extensions CRL et non des extensions d'entrée
CRL. Remarquez que certains logiciels (par exemple Netscape) ne gèrent pas les CRL V2. Consultez la page
de manuel x509v3_config(5) pour obtenir des précisions sur le format de section d'extensions.
OPTIONS DU FICHIER DE CONFIGURATION
La section du fichier de configuration contenant des options pour ca est trouvée de la façon suivante : si
l'option de ligne de commande -name est utilisée, elle précise le nom de la section à utiliser. Autrement, la
section qui sera utilisée est celle mentionnée l'option default_ca de la section ca du fichier de
configuration (ou dans la section par défaut du fichier de configuration). À part default_ca, les options
suivantes sont lues directement dans la section ca :
RANDFILE preserve
msie_hack
À l'exception de RANDFILE, c'est probablement un bogue et cela risque d'être modifié dans les prochaines
versions.
De nombreuses options du fichier de configuration sont identiques à celles de la ligne de commande. Si une
option est présente à la fois dans le fichier de configuration et sur la ligne de commande, la valeur de la
ligne de commande est prise en compte. Une option décrite comme obligatoire doit être présente soit dans le
fichier de configuration soit sur la ligne de commande (si c'est possible).
oid_file
Indique le fichier contenant des IDENTIFIANTS D'OBJET supplémentaires. Chaque ligne est constituée de la
forme numérique de l'identifiant d'objet suivie d'un espace puis du libellé court suivi à son tour d'un
espace et finalement du libellé long.
oid_section
Indique une section du fichier de configuration contenant d'autres identifiants d'objet. Chaque ligne est
constituée du libellé court de l'identifiant d'objet suivi de = et de la forme numérique. Le libellé court
et le libellé long sont identiques quand cette option est utilisée.
new_certs_dir
Identique à l'option de ligne de commande -outdir. Elle indique le répertoire où les nouveaux certificats
seront placés. Obligatoire.
certificate
Identique à -cert. Elle indique le fichier contenant le certificat de l'autorité de certification.
Obligatoire.
private_key
Identique à l'option -keyfile. Le fichier contenant la clef privée de l'autorité de certification.
Obligatoire.
RANDFILE
Un fichier utilisé pour lire et écrire les renseignements initiateurs de nombre aléatoire ou une socket
EGD (consultez RAND_egd(3)).
default_days
Identique à l'option -days. La durée en jour pendant laquelle le certificat sera certifié.
default_startdate
Identique à l'option -startdate. La date de début de validité du certificat. Si cette option est absente,
la date actuelle sera utilisée.
default_enddate
Identique à l'option -enddate. Soit cette option, soit default_days (où les équivalents en ligne de
commande) doivent être présent.
default_crl_hours default_crl_days
Identiques aux options -crlhours et -crldays. Uniquement utilisées si aucune des options n'est présente
sur la ligne de commande. Au moins une de ces options doit être indiquée pour générer une liste de
révocations de certificats.
default_md
Identique à l'option -md. Le type de condensé de message à utiliser. Obligatoire.
database
Le fichier texte (base de données) à utiliser. Obligatoire. Ce fichier doit être présent même s'il est
initialement vide.
unique_subject
Si la valeur yes est donnée, les entrées valables de certificat dans la base de données doivent avoir des
objets uniques. Si la valeur no est donnée, plusieurs entrées valables de certificat peuvent avoir les
mêmes objets. La valeur par défaut est yes, par compatibilité avec les plus anciennes versions d'OpenSSL
(avant 0.9.8). Cependant, pour faciliter le remplacement des certificats d'autorité de certification,
l'utilisation de la valeur no est recommandée, en particulier si combinée avec l'option -selfsign de la
ligne de commande.
serial
Un fichier texte contenant le prochain numéro de série à utiliser en hexadécimal. Obligatoire. Ce fichier
doit être présent et contenir un numéro de série valable.
crlnumber
Un fichier texte contenant le prochain numéro de liste de révocations de certificats à utiliser en
hexadécimal. Le numéro ne sera inséré dans les listes de révocations de certificats que si le fichier
existe. Si ce fichier est présent, il doit contenir un numéro de liste de révocations de certificats
valable.
x509_extensions
Identique à -extensions.
crl_extensions
Identique à -crlexts.
preserve
Identique à -preserveDN.
email_in_dn
Identique à -noemailDN. Si vous voulez que le champ EMAIL soit supprimé du DN du certificat, définissez-le
simplement à « no ». S'il n'est pas présent, le champ EMAIL sera permis dans le DN du certificat par
défaut.
msie_hack
Identique à -msie_hack.
policy
Identique à -policy. Obligatoire. Consultez la section FORMAT DES POLITIQUES pour plus de renseignements.
name_opt, cert_opt
Ces options permettent au format utilisé d'afficher les précisions du certificat lors de la demande de
confirmation de signature à l'utilisateur. Tous les paramètres pris en charge par les options -nameopt et
-certopt des utilitaires x509 peuvent être utilisés ici, sauf que no_signame et no_sigdump sont définis de
façon permanente et ne peuvent pas être désactivés (parce que le certificat n'a pas été signé à ce moment,
donc la signature du certificat ne peut pas être affichée).
Par commodité, les valeurs ca_default sont acceptées par les deux pour produire une sortie raisonnable.
Si aucune option n'est présente, le format utilisé dans les versions précédentes d'OpenSSL est utilisé.
L'utilisation de l'ancien format est fortement déconseillée, parce qu'il n'affiche que les champs
mentionnés dans la section policy, ne gère pas correctement les types de chaîne multicaractère et
n'affiche pas les extensions.
copy_extensions
Détermine la façon de traiter les extensions des demandes de certificat. Si définie à none, ou si cette
option n'est pas présente, alors les extensions sont ignorées et ne sont pas copiées vers le certificat.
Si définie à copy, toutes les extensions présentes dans la demande qui ne sont pas déjà présentes sont
copiées vers le certificat. Si définie à copyall, toutes les extensions de la demande sont copiées vers le
certificat : si l'extension est déjà présente dans le certificat, elle est d'abord supprimée. Consultez la
section AVERTISSEMENTS avant d'utiliser cette option.
L'utilisation principale de cette option est de permettre à une demande de certificat de fournir des
valeurs pour certaines extensions comme subjectAltName.
FORMAT DES POLITIQUES
La section policy consiste en un jeu de variables qui correspondent aux champs DN du certificat. Si la valeur
est « match », la valeur du champ doit être identique au champ du même nom du certificat de l'autorité de
certification. Si la valeur est « supplied », il doit être présent. Si la valeur est « optional », sa présence
n'est pas obligatoire. Tout champ ne figurant pas dans la section policy est supprimé à moins que l'option
-preserveDN ne soit activée, mais c'est plus une bizarrerie qu'un comportement attendu.
FORMAT SPKAC
L'entrée fournie à la ligne de commande -spkac est une clef publique signée Netscape et un défi. Cela provient
habituellement d'une balise KEYGEN dans un formulaire HTML pour créer une nouvelle clef privée. Il est
toutefois possible de créer des SPKAC en utilisant l'utilitaire spkac.
Le fichier devrait contenir la variable SPKAC avec la valeur de la clef SPARK ainsi que les éléments DN sous
forme de paires nom-valeurs. Si besoin est d'inclure le même élément plusieurs fois, il est possible de le
faire précéder par un nombre et un « . ».
EXEMPLES
Note : ces exemples supposent que l'arborescence ca est déjà en place et que les fichiers liés existent. Cela
nécessite généralement la création d'un certificat et d'une clef privée pour l'autorité de certification avec
req, un fichier de numéro de série et un fichier d'index vide. Tous ces fichiers doivent être placés dans les
répertoires correspondants.
Afin d'utiliser le fichier de configuration type ci-dessous, il faut créer les répertoires demoCA,
demoCA/prive et demoCA/nouvcerts. Le certificat de l'autorité de certification doit être copié dans
demoCA/certca.pem et sa clef privée dans demoCA/prive/clefca.pem. Un fichier demoCA/serie doit être créé
contenant par exemple « 01 » et un fichier d'index vide doit être créé dans demoCA/index.txt.
Signer une demande de certificat :
openssl ca -in dem.pem -out nouvcert.pem
Signer une demande de certificat utilisant des extensions d'autorité de certification :
openssl ca -in dem.pem -extensions v3_ca -out nouvcert.pem
Générer une liste de révocations de certificats :
openssl ca -gencrl -out crl.pem
Signer plusieurs demandes :
openssl ca -infiles dem1.pem dem2.pem dem3.pem
Certifier un SPKAC Netscape :
openssl ca -spkac spkac.txt
Un fichier SPKAC type (lignes tronquées pour la lisibilité) :
SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5
CN=Steve Test
emailAddress=steve@openssl.org
0.OU=Groupe OpenSSL
1.OU=Un autre groupe
Un fichier de configuration type avec les sections pour ca :
[ ca ]
default_ca = CA_defaut # la section ca par défaut
[ CA_defaut ]
dir = ./demoCA # répertoire principal
database = $dir/index.txt # fichier index
new_certs_dir = $dir/nouvcerts # rép. nouveaux certificats
certificate = $dir/certca.pem # le certificat de la CA
serial = $dir/serie # fichier de numéro de série
private_key = $dir/prive/clefca.pem # clef privée de la CA
RANDFILE = $dir/prive/.alea # fichier de numéro aléatoire
default_days = 365 # durée de certification
default_crl_days= 30 # durée avant la prochaine CRL
default_md = md5 # hachage à utiliser
policy = politique_def # politique par défaut
email_in_dn = no # pas d'adresse élec. dans le DN
name_opt = ca_default # option d'aff. de nom de sujet
cert_opt = ca_default # option d'aff. de certificat
copy_extensions = none # sans copie d'extensions de dem.
[ politique_def ]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
FICHIERS
Note : l'emplacement de tous les fichiers peut changer en fonction des options de compilation, des entrées
dans le fichier de configuration, des variables d'environnement ou des options de la ligne de commande. Les
valeurs ci-dessous sont les valeurs par défaut.
/usr/local/ssl/lib/openssl.cnf - fichier de configuration maître
./demoCA - répertoire principal de la CA
./demoCA/cacert.pem - certificat de la CA
./demoCA/private/cakey.pem - clef privée de la CA
./demoCA/serial - fichier des numéros de série de la CA
./demoCA/serial.old - sauvegarde de ./demoCA/serial
./demoCA/index.txt - base de données en texte de la CA
./demoCA/index.txt.old - sauvegarde de ./demoCA/index.txt
./demoCA/certs - fichier de sortie du certificat
./demoCA/.rnd - graine pour l'aléa de la CA
VARIABLES D'ENVIRONNEMENT
OPENSSL_CONF contient l'emplacement du fichier de configuration principal qui peut être modifié avec l'option
en ligne de commande -config.
RESTRICTIONS
Le fichier d'index est une partie cruciale du processus et toute corruption peut s'avérer difficile à
rattraper. Bien qu'il soit possible théoriquement de reconstruire l'index à partir des certificats délivrés et
d'une liste de révocations de certificats récente, aucune option ne permet de faire cela.
Les fonctionnalités des CRL V2 telles que la prise en charge des delta CRL ne sont pas gérées actuellement.
Même s'il est possible d'entrer et de traiter plusieurs demandes en même temps, il est impossible d'inclure
plus d'un SPKAC ou certificat autosigné.
BOGUES
L'utilisation d'une base de données texte en mémoire peut s'avérer problématique, en particulier avec un
nombre important de certificats à gérer, justement du fait que cette base se trouve en mémoire.
La commande ca a réellement besoin d'être réécrite ou les fonctionnalités nécessaires devraient être fournie
par une commande ou interface pour permettre à des utilitaires plus orientés utilisateurs (scripts Perl ou
interface graphique) de traiter les choses correctement. Les scripts CA.sh et CA.pl aident un petit peu en ce
sens.
Tous les champs d'une demande qui ne sont pas présents dans la politique sont supprimés silencieusement. Cela
n'arrive pas si l'option -preserveDN est utilisée. Pour renforcer l'absence du champ EMAIL dans le DN,
conformément aux suggestions des RFC, quelque soit le contenu de l'objet de la demande, l'option -noemailDN
peut être utilisée. Le comportement devrait être plus simple et configurable.
L'annulation de certaines commandes en refusant de certifier un certificat peut résulter en un fichier vide.
AVERTISSEMENTS
La commande ca est capricieuse et parfois peu facile d'utilisation.
La commande ca a eu pour objectif initial d'être un exemple montrant comment se servir d'une autorité de
certification. Elle n'a pas été créée pour servir d'application pour une autorité de certification complète,
cependant certaines personnes s'en servent dans ce but.
La commande ca est effectivement une commande mono-utilisateur, aucun verrouillage n'est fait sur les divers
fichiers, et des tentatives d'accès simultanées à un même fichier d'index peuvent produire des résultats
imprévisibles.
L'option copy_extensions devrait être utilisée avec précaution. Un risque de sécurité est possible si
l'attention nécessaire n'est pas fournie. Par exemple, si une demande de certificat contient une extension
basicConstraints avec CA:TRUE et que la valeur copy_extensions est définie à copyall et que l'utilisateur ne
s'en rend pas compte quand le certificat est affiché, alors cela fournira au demandeur un certificat
d'autorité de certification valable.
Cette situation peut être évitée en définissant copy_extensions à copy et en incluant basicConstraints avec
CA:FALSE dans le fichier de configuration. Dans ce cas, si la demande contient une extension basicConstraints,
elle sera ignorée.
Il est aussi conseillé d'inclure les valeurs pour les autres extensions comme keyUsage pour éviter qu'une
demande fournisse ses propres valeurs.
Des restrictions supplémentaires peuvent être ajoutées au certificat de l'autorité de certification lui-même.
Par exemple si le certificat de l'autorité de certification contient :
basicConstraints = CA:TRUE, pathlen:0
alors même si un certificat est émis avec CA:TRUE, il ne sera pas valable.
VOIR AUSSI
req(1), spkac(1), x509(1), CA.pl(1), config(5), x509v3_config(5)
TRADUCTION
Cette page de manuel a été traduite par stolck en 2002 et est maintenue par la liste <debian-l10n-french AT
lists DOT debian DOT org>. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le paquet
manpages-fr-extra.
1.0.1f 2014-02-01 CA(1SSL)
J'ai donc bien généré ce genre de certifias, mais il fonctionne pas comme je le voudrai... comment corriger ???
JM
Hors ligne
#8 Le 24/06/2014, à 14:33
- bruno
Re : [Résolu] pb openssl ca cacert
La commande ca est une application d'autorité de certification
Tu es une autorité de certification ?
Non, donc cela revient à être ta propre autorité de certification. On retombe exactement sur le même problème q'un certificat auto-signé.
Cacert.org est une autorité de certification, bien heureusement tu ne pas pas signer des certificats à sa place (en te faisant passer pour elle si tu préfères).
#9 Le 25/06/2014, à 09:07
- pti-jean
Re : [Résolu] pb openssl ca cacert
Bonjour,
Ok Bruno... j"avais pas compris ça!
Me vient alors un autre problème...
Je décide d'être moi même ma propre autorité...
Normalement si j'importe mon propre certificat racine dans mon navigateur, je devrai pouvoir rentré sur mon site sans avertissement du genre: "Cette connexion n'est pas certifiée"... or ce n'est pas le cas! d'où vient le problème ?
* Quand je parle d'importer le certificat racine, j'importe le fichier cacert.crt générer par cette cmd:
openssl req -new -x509 -extensions v3_ca -newkey rsa:4096 -keyout private/cakey.key -out certs/cacert.crt -days 3650 -config ./openssl.1.cnf
JM
Hors ligne
#10 Le 25/06/2014, à 09:54
- bruno
Re : [Résolu] pb openssl ca cacert
Si tu crées ta propre autorité de certification, il faut que le certificat de ton serveur soit signé par elle. Est-ce le cas ?
Voir par exemple : http://www.ixany.org/docs/SSL_AC_locale.html
Quoiqu'il en soit j'ai l'impression que tu te compliques la vie pour rien.
Cas 1 : ton site en https ne sert qu'à toi même (éventuellement une ou deux autres personnes). Le plus simple est d'utiliser une certificat auto-signé et lors de la première connexion indiquer au navigateur que l'on accorde définitivement sa confiance à ce site. La question ne sera plus posée.
Cas 2 : ton site en https doit être accessible à tous le monde. Avoir sa propre autorité de certification n'apporte aucun avantage puisqu'il faudra obliger les utilisateurs à installer le certificat de ton ACdans leur navigateur. La seule solution viable est d'utiliser une autorité de certification déjà intégrée aux navigateurs, donc acheter un certificat auprès d'un prestataire quelconque ou en obtenir un gratuit sur https://www.startssl.com/?lang=fr
Pour moi une autorité de certification locale n'a d’intérêt que dans le cadre d'un intranet où l'on peut déployer facilement le certificat de l'AC sur tous les postes.
#11 Le 25/06/2014, à 13:24
- pti-jean
Re : [Résolu] pb openssl ca cacert
bruno a écrit :Si tu crées ta propre autorité de certification, il faut que le certificat de ton serveur soit signé par elle. Est-ce le cas ?
Voir par exemple : http://www.ixany.org/docs/SSL_AC_locale.html
Exactement!
Moi, je me suis expiré de cet exemple:
http://www.site-sans-nom.org/rc2/sysadm … howto.html
Cas 3: pour trouver une solution technique à la problématique suivante: mon téléphone android n'accepte pas les certificats auto-signés, pour une raison dont je n'ai pas trouvé la réponse... alors que j'ai trouvé une procédure qui fonctionne pour importer dans mon android le certificat racine d'un autorité de certification:
http://wiki.cacert.org/FAQ/ImportRootCe … 26_Tablets
Je voulais donc valider la chose avec firefox, mais ça ne fonctionne pas!
Une idée ?
JM
Hors ligne
#12 Le 26/06/2014, à 14:46
- bruno
Re : [Résolu] pb openssl ca cacert
Désolé je ne sais pas comment faire accepter un certificat auto-signé (ou ajouter une autorité de certification) sur un terminal Androïd, mais je suppose que le web regorge de réponses à ce sujet.
#13 Le 26/06/2014, à 23:03
- pti-jean
Re : [Résolu] pb openssl ca cacert
Bonsoir,
Ben justement, j'ai trouvé aucun lien pour faire accepter un certificat auto-signé en ligne de commande sur un Android!!!
JM
Hors ligne
#14 Le 04/07/2014, à 13:54
- pti-jean
Re : [Résolu] pb openssl ca cacert
Bonjour,
En suivant cette documentation pour créer mon certificat, en étant moi même l'autorité de certification:
http://jeyg.info/des-certificats-signes … c-openssl/
en important le certificat racine de l'autorité de certification (moi même) dans Android en suivant cette documentation:
http://wiki.cacert.org/FAQ/ImportRootCe … 26_Tablets
Ma problématique est résolut... à savoir: faire fonctionner DAVDroid par https... mes contacts sont donc synchronisé sur mon Owncloud perso... ce qui représente une dépendance de moins en vers google.
JM
Hors ligne
Pages : 1