Hello,
Je viens de "finir" un projet de private key.
Le but est d'avoir une PKI, qui réponds au protocole ACME, et qui permette de générer des configuration OpenVPN.
Le poc est fonctionnel, j'ai testé], ça semble fonctionner de mon côté.
Je dois valider encore quelques trucs, et le code sera publié.
Je dev sur ma forge (gitlab auto hébergé), on m'a conseillé de publier le code sur GitHub. Mais je peux changer de fusil d'épaule.
Je cherche maintenant à savoir - une fois que tout ça est fait :
- Est-ce que ce type de produit peut intéresser du monde?
La licence sera une SSPL, donc code ouvert, mais utilisation corporate soumise à licence (dans ma tête, un lien vers le site du projet, autorisation écrite d'afficher l'utilisateur comme "Ils nous utilisent").
Est-ce que certains d'entre vous veulent des comptes pour tester?
Cordialement,
# Infrastructure
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4 (+2/-0).
Dans PKI, le "I" c'est pour infrastructure.
"Une infrastructure à clés publiques (ICP) ou infrastructure de gestion de clés (IGC) ou encore public key infrastructure (PKI), est un ensemble de composants physiques (des ordinateurs, des équipements cryptographiques logiciels) ou matériel type Hardware Security Module (HSM ou boîte noire transactionnelle) ou encore des cartes à puces, de procédures humaines (vérifications, validation) et de logiciels (système et application) destiné à gérer les clés publiques des utilisateurs d'un système."
Tu peux nous décrire en 3 phrases ton infrastructure cible ?
[^] # Re: Infrastructure
Posté par Richard DEMONGEOT (site web personnel) . Évalué à 7 (+7/-0).
Hello,
De manière très rapide, et actuellement :
Une interface/API disponible en web;
Un stockage MariaDB (clef chiffrées avec une option mdp utilisateur pour l'utilsiation).
Donc très méchament, une interface WEB à un openssl + le repo GIT :).
Mais l'interface permet de valider / révoquer les certificats, de pousser un CSR (comme des scripts shell, on est d'accord) etc.
A moyen terme, utilisation de nitrokey en guise d'HSM hardware (ou intégration avec un autre HSM)
et autre vision souhaité faire du Shamir Shared Secret entre 3 membres de l'entreprise pour dévérouiller la clef ROOT.
Dès que j'ai assez avancé, le SSS pourrait être fait à partir de NitroKey utilisateur (donc 2 sur 3 utilisateurs pour reconstituer le mdp de la clef root, donc pour signer l'intermédiaire).
Et surtout, à moyen terme, possiblité de faire du Single Sign On avec le compte LDAP d'entreprise, donc le flux de création de compte VPN deviendrai :
1/ L'employé est créé dans l'IT en tant que salarié;
2/ il se logue sur l'interface, "je veux mon compte VPN"
3/ son certificat utilisateur est généré, ajouté au fichier ovpn, téléchargé par l'utilisateur;
4/ ça fonctionne.
L'idée est la même pour l'authentification des postes en wifi, ou pour toute authentification par certificat en entreprise.
L'autre avantage, la RH peut révoquer le certificat, la CRL se met à jour, et (si le VPN la lit ou la met a jour régulièrement), le compte VPN est coupé.
[^] # Re: Infrastructure
Posté par cg . Évalué à 3 (+1/-0). Dernière modification le 28 février 2026 à 09:59.
Hello,
selon toi, comment ça se situe par-rapport à EJBCA, qui semble faire plus ou moins la même chose, et est sur le même créneau de marché avec une version "community" et une double licence ?
Ce serait d'intégrer les trucs autour de la PKI, comme le SSO, dans la même brique logicielle ?
(zut j'ai posté au mauvais endroit, je voulais démarrer un nouveau fil, tant pis)
[^] # Re: Infrastructure
Posté par Richard DEMONGEOT (site web personnel) . Évalué à 1 (+1/-0).
EJBCA community est très limité.
Tu n'a pas les authentification centralisées, pas la haute disponibilité, pas les modules pour générer les conf OpenVPN par exemple.
Quand j'avais regardé, c'était assez sommaire la version community, et très vite très cher pour la version enterprise.
# SPSPL
Posté par Faya . Évalué à 4 (+2/-0). Dernière modification le 27 février 2026 à 21:12.
VU qu'il en faut toujours un, je me dévoue : la SSPL Sa Pue, Sai Pas Libre.
Histoire d'agrémenter le commentaire, pourquoi cette licence et pas une licence libre ?
[^] # Re: SPSPL
Posté par Bruno (Mastodon) . Évalué à 1 (+0/-0).
Pour financer le projet avec ceux qui ont les moyens ?
C'est pas libre effectivement.
[^] # Re: SPSPL
Posté par Richard DEMONGEOT (site web personnel) . Évalué à 6 (+6/-0).
Je l'attendais cette remarque :)
Effectivement, c'est pas libre. Mais pour répondre honnêtement :
Purement personnel :
Certains "gros" que je connais voudraient l'utiliser sans aucune contre partie.
Cette licence, même si elle n'est pas libre, me permet d'avoir le code ouvert, et de bloquer cet usage.
Et d'entendre ces entreprises dire "de toute façon dans 3 mois tu met ça opensource et on l'utilise sans vergognes, sans aucun retour - je demandais juste qu'ils mentionnent le produit & que je puisse les mentionner - ça m'a un peu dégouté.
Seconde raison, après le temps de dev, si je peux vendre un service managé pour rentabiliser un peu, je prend, comme tout le monde, j'ai besoin de vivre et de nourrir les enfants.
Mais si vous avez mieux comme licence, je prend :).
[^] # Re: SPSPL
Posté par aiolos . Évalué à 6 (+4/-0).
Ce ne seraoit pas la license Affero qu’il te faut ? Obligation de fournir le code source aux utilisateurs de la version web. Donc, il sont obligé de parler de ton projet, et tu peux les citer puisque c’est public.
[^] # Re: SPSPL
Posté par Richard DEMONGEOT (site web personnel) . Évalué à 2 (+2/-0).
C'est pas sur du web qu'ils pensaient l'utiliser.
Que pour du pur backend interne chez eux.
Donc même si ils exposent le nom sur l'outil en lui même, utilisé par 2 personnes, ça ne changera rien :/
Mais je vais relire la affero pour confirmer :)
[^] # Re: SPSPL
Posté par bbo . Évalué à 2 (+0/-0).
Je pense que l'AGPL ne changera rien sur ce genre de logiciel pour les entreprises.
Ça n'aurait un impact (relatif) que sur les entreprises qui font du PKI-as-a-service.
Pour toutes les autres, la PKI sera interne à l'infrastructure, non ? Si modifié, le code source n'aurait donc qu'à être diffusé sur le Gitlab interne de l'entreprise et hop, "les utilisateurs du logiciel ont bien accès au code source"
[^] # Re: SPSPL
Posté par Richard DEMONGEOT (site web personnel) . Évalué à 2 (+2/-0).
C'est ce que j'avais en tête aussi.
J'aimerai publier en GPL / BSD, et c'est un objectif moyen / long terme.
Mais je veux me protéger d'autres PKI A-A-S; et tenter d'éviter du canibalismes dans certains cas.
J'ai peu d'espoir, car je sais très bien que
1/ il faut être au courant qu'ils l'utilisent;
2/ le prouver;
3/ prouver que ça viole la licence.
Donc dans les fait, c'est presque plus pour me rassurer qu'autre chose :). Mais voila.
[^] # Re: SPSPL
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Oui, l'histoire de l'AGPL comme repoussoir des hyperscalers, c'est un peu de la propagande du à Google, et tout le monde suit sans trop réfléchir.
En pratique, je ne pense pas qu'on puisse dire qu'il y a plus de souci avec l'AGPL ou la GPL surtout si tu ne modifies rien (comme la majorité des gens en pratique), et les contentieux en France sur le logiciel libre sont quand même rare (4 ou 5 depuis l'existence de la GPL si je me souviens bien, donc ça fait grosso modo 1 tout les 10 ans en moyenne même si en pratique, c'est plus sur les 20 dernières années que les 20 premières).
[^] # Re: SPSPL
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Je sais pas de qui tu parles, mais les gros en question dont on parle en général dans le contexte de la SSPL ont déjà ce genre de service. Par exemple, AWS a 2 services de VPN intégré avec IAM, Azure a un produit Azure VPN Gateway, GCP propose Cloud VPN. Donc je doute fort que ces gros la se préoccupent de ton logiciel, et j'ai toujours trouvé cet argument pour la SSPL comme assez proche d'une illusion de grandeur de la part des créateurs de logiciels (je suppose que ça va avec la création d'entreprise).
Et la SSPL pose aussi des tas de soucis. Il y a les questions de confusions dont je parle dans un billet (enfin la, c'est pour la BSL), mais aussi des trucs tout cons, comme ne pas pouvoir utiliser les services pour les projets libres (exemple, Open Collective, ou divers outils intégrés dans Github), et surtout devoir appliquer le CRA en entier comme un projet proprio et pas les trucs simplifiés des articles 24/25 comme les logiciels libres. C'est loin d'être négligeable à mon avis.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.