Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Juillet 2018 -
Ce court RFC ajoute aux
certificats PKIX du
RFC 5280 la possibilité de contenir
des adresses de
courrier électronique dont la partie
locale est en
Unicode. Et il modifie légèrement les
règles pour les noms de domaine en
Unicode dans les certificats.
Les certificats sur
l'Internet sont normalisés dans le RFC 5280, qui décrit un profil de
X.509 nommé PKIX
(définir un profil était nécessaire car la norme X.509 est bien
trop riche et complexe). Ce RFC 5280
permettait des noms de domaine en
Unicode (sections 4.2.1.10 et 7 du RFC 5280) mais il suivait l'ancienne norme
IDN, celle des RFC 3490 et suivants. Depuis, les IDN sont normalisés dans
le RFC 5890 et suivants, et notre nouveau
RFC 8399 modifie très légèrement le RFC 5280 pour s'adapter à cette nouvelle norme de noms de
domaines en Unicode. Les noms de domaine dans un
certificat peuvent être présents dans les champs Sujet (titulaire
du certificat) et
Émetteur (AC ayant signé le certificat) mais aussi dans les contraintes sur le nom (une
autorité de certification peut être
limitée à des noms se terminant en
example.com, par exemple).
Notez que, comme avant, ces noms sont
exprimés dans le certificat en Punycode
(RFC 3492, xn--caf-dma.fr au lieu de
café.fr). C'est un bon exemple du fait que
les limites qui rendaient difficiles d'utiliser des noms de
domaine en Unicode n'avaient rien à voir avec le DNS
(qui n'a jamais
été limité à ASCII, contrairement à ce qu'affirme une
légende courante). En fait, le problème venait des applications
(comme PKIX), qui ne s'attendaient pas à
des noms en Unicode. Un logiciel qui traite des certificats
aurait été bien étonné de voir des noms de domaines
non-ASCII, et aurait peut-être
planté. D'où ce choix du Punycode.
Nouveauté plus importante de notre RFC 8399, les
adresses de courrier électronique en
Unicode. Elles étaient déjà permises par la section 7.5 du RFC 5280, mais seulement pour la partie domaine
(à droite du @). Désormais, elles sont
également possibles dans la partie locale (à gauche du @). Le
RFC 8398 donne tous les détails sur ce sujet.
Reste à savoir quelles AC vont accepter
Unicode. J'ai testé avec Let's
encrypt (avec le client Dehydrated, en mettant le
Punycode dans domains.txt) et ça marche, regardez le certificat de
https://www.potamochère.fr/
% gnutls-cli www.potamochère.fr
...
- subject `CN=www.xn--potamochre-66a.fr', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x03ed9617bb88bab3ad5b236675d1dd6e5d27, ...
D'autres AC acceptent ces noms en Unicode :
Gandi le fait aussi, regardez le certificat
de
https://réussir-en.fr. On
notera que le célèbre service de test de la qualité des
configurations TLS,
SSLlabs, gère bien les IDN :
