Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#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