Le Trousseau d’accès est toujours présent sur chaque Mac, et son Assistant certificat génère toujours des demandes de signature de certificat. Que cette demande soit utile pour la signature de code dépend entièrement du certificat que vous commandez. Pour un certificat Apple Developer ID, celui qui vous permet de distribuer des logiciels Mac en dehors du Mac App Store, le Trousseau d’accès est le bon outil et les étapes ci-dessous sont d’actualité. Pour un certificat de signature de code commercial délivré par une autorité de certification publique, le type utilisé pour signer les exécutables Windows, les installateurs, les pilotes et les applications Java, une demande générée dans le Trousseau d’accès n’est plus acceptée depuis le 1er juin 2023, car la clé privée doit désormais être créée sur du matériel dédié.
Déterminez d’abord lequel des deux vous concerne, puis suivez la section correspondante.
Quel certificat de signature de code obtenez-vous réellement ?
Les deux produits sont appelés certificats de signature de code et prouvent tous deux qui a publié un logiciel, mais ils proviennent d’émetteurs différents et suivent des règles différentes. Les lecteurs arrivent sur cette page parce qu’Apple et les autorités de certification publiques utilisent les mêmes termes pour deux choses différentes.
- Certificat Apple Developer ID. Délivré par Apple, sous sa propre autorité de certification Developer ID, aux membres de l’Apple Developer Program. Il signe les applications Mac, les plug-ins et les paquets d’installation que vous distribuez vous-même, afin que macOS Gatekeeper vous reconnaisse comme développeur identifié. La paire de clés est générée sur votre Mac et reste dans votre trousseau de connexion, et vous créez la demande dans le Trousseau d’accès.
- Certificat de signature de code de confiance publique. Acheté auprès d’une autorité de certification publique telle que Sectigo, DigiCert ou GlobalSign. Il signe les exécutables Windows, les installateurs MSI, les pilotes, les scripts PowerShell et les applications Java. Il est régi par les exigences de base du CA/Browser Forum pour la signature de code, qui imposent que la clé privée soit générée et reste sur du matériel certifié, de sorte qu’il n’y a rien à faire dans le Trousseau d’accès.
La règle de décision rapide : si le logiciel que vous signez fonctionne sur macOS et que vous le distribuez en dehors du Mac App Store, vous avez besoin d’un certificat Developer ID. Si vous signez quoi que ce soit pour Windows, ou une application Java, vous avez besoin d’un certificat de signature de code commercial, même si vous le construisez sur un Mac. Aucun des deux n’est un certificat SSL/TLS. Si ce que vous cherchez réellement est le HTTPS sur un serveur Mac, suivez plutôt le guide comment générer une CSR sur les serveurs macOS.
La voie commerciale : pourquoi la méthode du Trousseau ne s’applique plus
Depuis le 1er juin 2023, les exigences de base du CA/Browser Forum pour la signature de code imposent que la clé privée de tout certificat de signature de code de confiance publique, standard (OV) comme à validation étendue (EV), soit générée et stockée dans un module cryptographique matériel conforme au niveau FIPS 140-2 Level 2, aux Critères Communs EAL4+, ou à une norme équivalente, et qu’elle soit non exportable. La signature de code EV a toujours exigé du matériel dédié ; le changement de 2023 a étendu la même règle aux certificats standard.
Une clé créée par l’Assistant certificat échoue à ce test par conception, pour trois raisons distinctes :
- La clé est un matériel logiciel exportable. Elle est écrite dans votre trousseau de connexion, et vous pouvez la sélectionner et l’exporter sous forme de fichier .p12. Cette portabilité est pratique pour le développement Apple et constitue exactement la propriété que l’exigence matérielle vise à supprimer.
- La taille de la clé ne correspond pas. Les exigences de base imposent un minimum de RSA 3072 bits pour la signature de code, et le menu Taille de la clé de l’Assistant certificat ne propose pas d’option 3072.
- La demande ne contient presque aucune identité. L’Assistant certificat ne demande qu’un nom commun et des adresses e-mail. Il n’y a nulle part où saisir les informations sur l’organisation, la localité, l’État ou le pays qu’une autorité de certification valide pour un certificat de signature de code à validation d’organisation.
Il reste donc deux méthodes valables pour obtenir un certificat de signature de code de confiance publique, et celle que vous utilisez est déterminée au moment de la commande :
- Jeton plus expédition. L’autorité de certification génère la paire de clés et la demande sur un jeton USB certifié de son côté, y charge le certificat émis, et vous envoie le jeton par la poste. Vous n’avez aucune CSR à créer ou à coller où que ce soit. Consultez quelle méthode de livraison de certificat de signature de code choisir.
- Votre propre jeton matériel, HSM ou HSM cloud, avec attestation. Vous générez la clé à l’intérieur de l’appareil, y produisez la demande, et soumettez un fichier d’attestation prouvant que la clé a été créée sur du matériel conforme et ne peut pas être exportée. Suivez le guide génération de CSR et attestation avec YubiKey 5 FIPS ou le guide CSR et attestation avec Luna Network Attached HSM v7.x, ou la documentation propre à votre fournisseur de HSM.
Un autre changement déjà entré en vigueur : le vote CSC-31 a réduit la validité maximale des certificats de signature de code de confiance publique de 39 mois à 460 jours pour les certificats émis à partir du 1er mars 2026, de sorte que les renouvellements reviennent désormais tous les 15 mois environ. Pour une vue d’ensemble, consultez comment générer une CSR pour un certificat de signature de code et la version OpenSSL du même guide.
Générer la CSR dans le Trousseau d’accès pour un certificat Apple Developer ID
Si vous avez déjà enregistré un fichier .certSigningRequest, passez directement à sa soumission dans votre compte développeur.
Deux choses à vérifier avant de commencer. Vous avez besoin d’une adhésion à l’Apple Developer Program, et Apple exige le rôle de titulaire du compte pour créer un certificat Developer ID. Vous êtes également autorisé à disposer d’un maximum de cinq certificats Developer ID Application et de cinq certificats Developer ID Installer par équipe. Le portail vous demande de télécharger une demande à chaque création de certificat, alors répétez cette procédure une fois par certificat.
Étape 1 : ouvrir le Trousseau d’accès et lancer la demande
Le Trousseau d’accès ne se trouve plus là où le disent la plupart des tutoriels. Jusqu’à macOS Sonoma, il se trouvait dans Applications > Utilitaires. À partir de macOS Sequoia, Apple l’a déplacé vers /System/Library/CoreServices/Applications/, un dossier système que le Finder n’affiche pas lorsque vous parcourez les applications, de sorte que chercher dans Utilitaires ne donne désormais aucun résultat. Les moyens les plus rapides de l’ouvrir sont Spotlight (appuyez sur Commande-Espace et tapez Trousseau d’accès), ou une simple commande dans le Terminal :
open "/System/Library/CoreServices/Applications/Keychain Access.app"Une fois l’application ouverte, choisissez Trousseau d’accès > Assistant certificat > Demander un certificat à une autorité de certification dans la barre de menus.
Avant cela, cliquez sur une zone vide de la liste des éléments afin que rien ne soit sélectionné. Si une clé ou un certificat est mis en surbrillance, l’élément de menu devient Demander un certificat à une autorité de certification avec suivi du nom de cet élément, et il construit la demande à partir de la clé existante au lieu d’en créer une nouvelle paire. C’est utile lorsque vous souhaitez délibérément réutiliser une clé, et déroutant sinon.
Étape 2 : remplir la fenêtre des informations sur le certificat
L’Assistant certificat s’ouvre sur un panneau intitulé Informations sur le certificat. Il demande très peu de choses :
- Adresse e-mail de l’utilisateur : l’adresse e-mail associée à votre compte Apple Developer.
- Nom commun : une étiquette pour la paire de clés, par exemple Developer ID Application Key. Ce n’est pas le nom qui figurera dans le certificat final. Apple construit le sujet du certificat émis à partir de votre équipe, sous la forme Developer ID Application : Nom de votre équipe (TEAMID), donc traitez ce champ comme votre propre référence.
- Adresse e-mail de l’AC : laissez-la vide. Elle n’est utilisée que par l’autre méthode de livraison.
- La demande est : sélectionnez Enregistrée sur le disque, et non Envoyée par e-mail à l’AC. Le portail développeur d’Apple accepte un fichier téléchargé.
Si vous souhaitez également choisir la taille de la clé ou l’algorithme, cochez ici Me laisser spécifier les informations de la paire de clés. Cliquez ensuite sur Continuer.
Étape 3 : choisir les paramètres de la paire de clés, si nécessaire
Ce panneau n’apparaît que si vous avez coché la case à l’étape 2, et pour un certificat Developer ID, vous pouvez normalement l’ignorer. Les valeurs par défaut sont RSA à 2048 bits, ce qui correspond aux instructions officielles d’Apple. Avec RSA sélectionné, le menu Taille de la clé propose 2048, 4096 et 8192 bits. Le menu Algorithme propose RSA et ECC, et le passage à ECC remplace ces tailles par 256, 384 et 521 bits. Laissez l’algorithme sur RSA sauf si le service auprès duquel vous vous inscrivez demande spécifiquement une clé à courbe elliptique.
Les versions précédentes de ce guide vous indiquaient de sélectionner au moins 3072 bits à ce stade. Ce chiffre est le minimum du CA/Browser Forum pour les certificats de signature de code commerciaux. Il ne s’applique pas à Developer ID, et n’est pas proposé dans ce menu, donc il n’y a rien à sélectionner. Cliquez sur Continuer.
Étape 4 : enregistrer la demande et vérifier son contenu
Choisissez l’emplacement d’enregistrement du fichier et cliquez sur Enregistrer. Vous obtenez un fichier avec l’extension .certSigningRequest, et l’Assistant certificat place également la paire de clés correspondante dans votre trousseau de connexion. Le fichier lui-même est du texte PEM ordinaire, vous pouvez donc l’ouvrir dans TextEdit et le lire, bien que le bloc encodé ne vous en apprenne pas beaucoup en soi.
Pour confirmer les détails avant de le télécharger, décodez la demande dans le Terminal. Cela fonctionne avec la commande openssl déjà présente sur macOS, qui est en réalité LibreSSL plutôt qu’OpenSSL proprement dit, donc il n’y a rien à installer :
openssl req -noout -text -in CertificateSigningRequest.certSigningRequestVérifiez trois éléments dans le résultat : la ligne Subject affiche le nom commun et l’adresse e-mail que vous avez saisis, la ligne de la clé publique indique 2048 bit (ou la taille que vous avez choisie), et l’algorithme de signature est SHA-256. Si vous préférez ne pas utiliser le Terminal, collez le contenu du fichier dans notre décodeur de CSR pour lire les mêmes champs.
Étape 5 : soumettre la demande et installer le certificat
Connectez-vous à votre compte Apple Developer et ouvrez Certificates, Identifiers & Profiles. Cliquez sur Certificates dans la barre latérale, puis sur le bouton d’ajout, et sous Software, sélectionnez Developer ID. Choisissez le type dont vous avez besoin :
- Developer ID Application signe une application Mac, un plug-in ou un bundle.
- Developer ID Installer signe un paquet d’installation Mac contenant votre application signée.
Cliquez sur Continue, puis sur Choose File, sélectionnez votre fichier .certSigningRequest, cliquez à nouveau sur Continue, puis sur Download. Apple renvoie un fichier de certificat avec l’extension .cer. Double-cliquez dessus pour l’installer, et il apparaît dans le Trousseau d’accès sous Mes certificats, associé à la clé privée créée à l’étape 4.
Signer avec le certificat ne représente que la moitié de ce que vérifie macOS. Gatekeeper s’attend à ce que les logiciels téléchargés en dehors du Mac App Store soient signés avec un certificat Developer ID et notarisés par Apple, alors soumettez la version signée à la notarisation avant de la distribuer. La notarisation ne remplace pas la signature, elle vient s’y ajouter.
Trouver la clé privée et la sauvegarder
Le certificat ne vaut rien sans la clé privée générée par l’Assistant certificat, et cette clé n’existe qu’à un seul endroit tant que vous ne l’avez pas copiée. Pour la trouver, ouvrez le Trousseau d’accès, sélectionnez le trousseau connexion, puis la catégorie Clés, et recherchez le nom commun que vous avez saisi à l’étape 2. Vous verrez deux entrées sous ce nom, une clé publique et une clé privée. Notez que la clé publique n’est pas votre CSR : la CSR est le fichier .certSigningRequest que vous avez enregistré sur le disque.
Une fois le fichier .cer installé, regardez plutôt sous Mes certificats. Là, le certificat et sa clé privée apparaissent comme une seule entrée, qui constitue l’identité de signature utilisée par codesign, Xcode et vos scripts de compilation. Pour transférer cette identité vers un autre Mac ou vers un serveur de compilation, faites un clic droit sur l’entrée et choisissez Exporter, ce qui produit un fichier .p12 protégé par un mot de passe que vous définissez. Conservez ce fichier comme vous conserveriez toute clé de signature, car quiconque le possède avec le mot de passe peut signer des logiciels en votre nom.
Sauvegardez-le avant d’en avoir besoin. Les certificats Developer ID sont valables cinq ans et ne peuvent pas être renouvelés : lorsqu’un certificat expire, vous en créez un nouveau. Si vous perdez la clé privée, le certificat ne peut plus jamais être utilisé et vous devez en créer un autre, ce qui consomme l’un de vos cinq emplacements Developer ID Application ou Developer ID Installer. Résistez à l’envie de révoquer l’ancien certificat pour faire le ménage. Apple indique explicitement qu’une application signée avec un certificat Developer ID révoqué ne s’installera pas, et ne se lancera pas pour un utilisateur qui la possède déjà, donc révoquer casserait toutes les copies déjà en circulation. Ne révoquez que si la clé a réellement été volée, et attendez-vous alors à cette rupture.
Un point d’entretien pour ceux qui sont arrivés ici pour un certificat commercial : si vous avez déjà généré une paire de clés dans le Trousseau d’accès pour une commande auprès d’une autorité de certification publique, elle ne peut pas être utilisée et aucune AC ne l’acceptera. Rien ne se casse si vous la laissez en place, mais il y a peu de raisons de conserver un matériel de clé de signature exportable dans un trousseau. Sélectionnez à la fois la clé publique et la clé privée sous Clés et supprimez-les, puis commandez plutôt via un jeton ou un HSM.
Questions fréquemment posées
Pour un certificat Apple Developer ID, oui, et c’est la méthode documentée par Apple. Pour un certificat de signature de code de confiance publique délivré par une autorité de certification commerciale, non. Depuis le 1er juin 2023, ces clés privées doivent être générées et stockées sur un module cryptographique matériel conforme au niveau FIPS 140-2 Level 2, aux Critères Communs EAL4+, ou à une norme équivalente, et une clé créée dans le Trousseau d’accès est un matériel logiciel exportable.
Dans /System/Library/CoreServices/Applications/. Apple l’y a déplacé avec macOS Sequoia, il ne se trouve donc plus dans Applications > Utilitaires et n’apparaît pas lorsque vous parcourez les applications dans le Finder. Ouvrez-le avec Spotlight, ou exécutez open "/System/Library/CoreServices/Applications/Keychain Access.app" dans le Terminal. L’application Mots de passe distincte introduite en parallèle ne gère que les mots de passe, pas les certificats et les clés.
RSA 2048 bits pour un certificat Developer ID, ce qui est la valeur par défaut, vous pouvez donc laisser Me laisser spécifier les informations de la paire de clés décoché. Avec RSA sélectionné, le menu Taille de la clé propose 2048, 4096 et 8192 bits, et le passage à ECC les remplace par 256, 384 et 521 bits. Aucun paramètre n’offre 3072 bits, qui est le minimum du CA/Browser Forum pour les certificats de signature de code commerciaux, et c’est l’une des raisons pour lesquelles cette voie ne convient pas à une commande commerciale.
Parce que la demande qu’il construit ne contient qu’un nom commun et des adresses e-mail. Apple n’a pas besoin de plus : il remplit le sujet d’un certificat Developer ID à partir de votre compte développeur. Une autorité de certification commerciale, elle, a besoin de détails sur l’organisation, et les valide par rapport à des registres publics, ce qui est une autre raison pour laquelle une demande du Trousseau ne convient pas à ce type de commande.
Non. La règle matérielle du CA/Browser Forum s’applique aux certificats de signature de code de confiance publique délivrés par des autorités de certification commerciales. Les certificats Developer ID sont délivrés par la propre autorité de certification d’Apple aux membres de l’Apple Developer Program, et la clé est générée dans votre trousseau de connexion par l’Assistant certificat, exactement comme décrit ci-dessus.
Générez-en une pour chacun. Le portail développeur vous demande de télécharger une demande de signature de certificat à chaque création de certificat, et donner à chaque identité sa propre paire de clés signifie que le remplacement ou la révocation de l’une d’elles laisse intact le logiciel signé avec l’autre. Donnez à chaque demande un nom commun que vous pourrez distinguer plus tard dans le Trousseau d’accès.
Vérifiez la catégorie Clés du trousseau connexion, en recherchant le nom commun que vous avez saisi plutôt que le nom du fichier. Si elle est réellement absente, les causes habituelles sont que la paire de clés a été créée sur un autre Mac ou sous un autre compte utilisateur, que l’élément du trousseau a été supprimé, ou que la demande a été construite à partir d’une clé existante avec la variante Demander un certificat à une autorité de certification avec de l’élément de menu. Sans la clé privée, la demande ne peut pas être utilisée, alors générez-en une nouvelle.
Les certificats de signature de code de confiance publique délivrés à partir du 1er mars 2026 sont plafonnés à 460 jours, réduits par rapport aux 39 mois précédents suite au vote CSC-31 du CA/Browser Forum. Les certificats Apple Developer ID sont valables cinq ans et sont remplacés plutôt que renouvelés. Dans les deux cas, les logiciels que vous avez signés pendant que le certificat était valide continuent de fonctionner après son expiration, à condition que la signature ait été horodatée. Apple applique une exception : il vérifie le certificat Developer ID Installer au moment où un paquet d’installation s’exécute, de sorte qu’un fichier .pkg doit être re-signé une fois ce certificat expiré, même si l’application qu’il contient n’est pas affectée.
Pour aller plus loin, consultez nos tutoriels sur la signature de code, les autres méthodes pour générer une CSR, et comment signer un fichier EXE à l’aide d’un certificat de signature de code.
Economisez 10% sur les certificats SSL en commandant aujourd’hui!
Émission rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon: SAVE10
