Devenir sa propre autorité de certification
Ces derniers temps et de plus en plus souvent, le protocole TLS (anciennement SSL) et surtout son implémentation dans le protocole HTTP (ce qui donne le HTTPS) est au cœur de nombreux et vifs débats quant à la sécurité toute relative que représente la méthode d'authentification la plus répandue : l'authentification du client TLS par certificat numérique.
L'authentification du client TLS par certificat numérique, qu'es aquò ?
C'est quand le client (vous, par l'intermédiaire de notre navigateur Web) authentifie le serveur TLS sur lequel il se connecte (le site de votre banque, votre boîte e-mail sur un portail Web, etc.). Cette authentification est réalisée via l'utilisation d'un certificat numérique (sorte de carte d'identité virtuelle approuvée par un tiers de confiance) X.509 (norme cryptographique des télécoms) délivré par une autorité de certification (CA). Votre navigateur Web embarque tout un tas de certificats dits racines, c'est à dire issus directement des autorités de certification (commerciales pour leur très grande majorité) et auto-signés. Ces certificats font office d'autorités connues et permettent d'en signer d'autres (moyennant finance) : votre banque, par exemple, achète auprès d'une autorité de certification racine, disons VISA, une certification (et donc un certificat d'autorité intermédiaire) afin de pouvoir créer ses propres certificats signés par celui (racine) de VISA. Ainsi, votre navigateur Web embarquant le certificat racine de VISA, il pourra établir une connexion sécurisée au site de votre banque de manière totalement transparente pour vous : le certificat de la banque étant signé par VISA et le certificat de VISA étant reconnu comme de confiance, le navigateur fera automatiquement confiance au certificat de la banque. Vous suivez ?
Et alors ? Il est où le problème ?
Eh bien, il réside principalement dans le fait que ces autorités de certification sont — je l'ai déjà dit — des entreprises commerciales (dont le but est donc de faire des profits) voire des fournisseurs d'accès ou même des gouvernements, qui prennent des intermédiaires, délèguent à des intermédiaires qui font de même, ne sont pas à l'abri d'une malveillance ou d'un piratage et qu'aussi, on peut tout à fait légitimement ne pas vouloir leur faire confiance (perso, un certificat du gouvernement birman, je me méfierais…)
- les intermédiaires : Paul est le plus grand sage du village, tout le monde lui fait absolument confiance. Paul signe un papier à Nathalie indiquant qu'il accorde à Nathalie toute sa confiance. Nathalie fait de même avec Jacques, Clara et Maxime, qui font ensuite de même avec… Car oui : toute autorité de certification racine peut délivrer un certificat intermédiaire à qui bon lui semble. Ça vous parle ?
- malveillance ou piratage : le système des certificats repose sur une infrastructure à clefs publiques, c'est-à-dire qu'une clef publique est disponible à quiconque la veut et que cette clef permet de déchiffrer ce qui a été chiffré avec la clef privée correspondante. Par exemple, une autorité de certification utilise sa clef privée pour créer un certificat, puis tout le monde peut vérifier que le certificat est authentique en utilisant la clef publique associée. Un système très efficace… tant que la clef privée ne se retrouve pas dans la nature, comme c'est arrivé récemment à l'autorité de certification racine Comodo : une clef privée d'un de leurs intermédiaires ayant été compromise, plusieurs certificats frauduleux ont vu le jour, impactant des sites tels que ceux de Live, GMail ou Mozilla. Comme les certificats frauduleux avaient été créés avec la clef privée de l'intermédiaire lui-même agrée par Comodo dont les certificats racines sont intégrés d'office dans les navigateurs Web, vous imaginez bien que lesdits navigateurs n'y ont vu que du feu.
- accorder sa confiance : dans un pays comme la Chine, le gouvernement possède ses propres certificats racines qui sont évidemment installés dans tous les navigateurs. Cela signifie qu'au regard du gouvernement chinois, que vous vous connectiez en HTTP ou HTTPS ne fait aucune différence. La Chine c'est loin, me direz-vous, mais vu le nombre d'intermédiaires plus ou moins douteux, ça pourrait très bien arriver n'importe où (et d'ailleurs, c'est le cas, même si ce n'est pas forcément mis en place par un gouvernement ou à l'échelle d'une nation).
Je ne peux que vous inviter à lire les articles de SebSauvage à ce sujet ici et là et si vous ne le connaissez pas encore, prenez le temps de parcourir son site et de lire ses coups de gueule, ça vaut le coup.
C'est bien joli tout ça. Et donc… ?
Et donc, c'est suite à un article de Mitsukarenai que j'ai commencé à doucement y gamberger : il avait déjà franchi le cap d'être sa propre autorité de certification racine et titrait fort à propos (exception faite de l'utilisation de « SSL » en lieu et place de « TLS ») : SSL: la chaîne de confiance brisée. Depuis, je n'ai toujours pas trouvé la solution idéale (et gagné des milliards avec (≧∇≦)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼), du genre chaîne de confiance véritable un peu dans le principe du WOT mais décentralisé + authentification DNS avec des DNS eux aussi décentralisés, mais la décision d'hier de Mitsukarenai (décidément toi, tu m'inspires ヽ(≧∇≦)ﾉ) de passer tout (ou presque) Fansub Streaming en HTTPS forcé m'a décidé à franchir un cap : créer ma propre autorité de certification racine. Ce qui nous amène directement au sujet principal de ce billet.
Be Your Own CA : comment devenir sa propre autorité de certification racine.
Ce qui suit est une adaptation de l'excellent tutoriel de David Pashley auquel vous pouvez vous reporter pour plus de détails.
Avant toute chose, il faut installer OpenSSL :
# apt-get install openssl
Puis l'on crée les répertoires qui vont accueillir notre certificat racine :
# mkdir -p /etc/own_ca/{conf,private,public} && chmod 400 /etc/own_ca/private
Cela va créer /etc/own_ca qui contiendra les répertoires conf, private et public.
- conf contiendra la configuration d'OpenSSL pour notre certificat racine
- private contiendra notre clef privée de CA
- public contiendra les certificats générés à l'aide de notre certificat racine
On se place dans le répertoire et on crée maintenant notre fichier de configuration pour OpenSSL :
# cd /etc/own_ca && vi conf/openssl.cnf
Dans ce fichier nous allons écrire ceci :
[ req ] default_bits = 4096 default_keyfile = ./private/root.pem default_md = sha1 prompt = no distinguished_name = root_ca_distinguished_name x509_extensions = v3_ca [ root_ca_distinguished_name ] countryName = FR stateOrProvinceName = Ile-de-France localityName = Paris 0.organizationName = MaCompagnie SA commonName = MaCompagnie SA Root CA emailAddress = adresse@domaine.tld [ v3_ca ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = CA:true
Bien évidemment, vous devez remplacer ce qui est en rouge par vos propres informations.
Ensuite, nous pouvons créer notre clef :
# openssl req -nodes -config conf/openssl.cnf -days 3650 -x509 -newkey rsa:4096 -out public/root.pem -outform PEM
Votre terminal vous affiche alors un truc comme ça :
Generating a 4096 bit RSA private key ...........................................................++ ..............................++ writing new private key to './private/root.pem' -----
problems making Certificate Request
20347:error:0D07A098:asn1 encoding routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:147:minsize=1
c'est que vous avez oublié de renseigner un champ dans la section root_ca_distinguished_name, comme par exemple le champ stateOrProvinceName qu'on pourrait être tenté de laisser vide en France.
Vous avez donc votre clef privée dans private/root.pem et votre clef publique dans public/root.pem ; clefs de 4096 bits valides pour une durée de dix ans. Il nous faut maintenant le distribuer et le moyen le plus simple pour cela est de placer sur notre site un lien vers notre signature toute neuve :
# cp public/root.pem /var/www/mon-site.tld/MaCompagnie-SA.crt
Pour être certains que les clients reconnaissent correctement le fichier, nous le servons en déclarant son type MIME au serveur web :
Nginx :
# vi /etc/nginx/mime.types
on ajoute :
application/x-x509-ca-cert der pem crt cert;
dans la liste (s'il n'y est pas déjà).
Apache :
# vi /etc/apache2/httpd.conf
on ajoute :
AddType application/x-x509-ca-cert .crt .cert .pem
Comme certains clients demandent que la clef soit au format DER et que certains autres ont besoin que le nom de la clef soit le hash du certificat, nous allons créer ces deux clefs :
# openssl x509 -in public/root.pem -outform DER -out public/root.der # cp public/root.pem public/$(openssl x509 -noout -hash -in public/root.pem).0
Puisque nous avons nos clefs de CA racine, il faut que nous puissions signer les requêtes de certificats (CSR), c'est précisément dans ce but que nous faisons tout ceci :D !
On rouvre notre openssl.cnf :
# vi conf/openssl.cnf
On ajoute ceci à la suite de notre configuration :
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = .
new_certs_dir = ./signed-keys/
database = ./conf/index
certificate = ./public/root.pem
serial = ./conf/serial
private_key = ./private/root.pem
x509_extensions = usr_cert
name_opt = ca_default
cert_opt = ca_default
default_crl_days = 30
default_days = 365
default_md = sha1
preserve = no
policy = policy_match
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ usr_cert ]
basicConstraints=CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
nsCaRevocationUrl = https://domaine.tld/exemple-ca-crl.pem
Sous la section [ CA_default ] vous pouvez éventuellement modifier la valeur de default_days qui règle la durée de validité par défaut des certificats que vous signez (365 jours en l'occurrence). N'oubliez pas de modifier la valeur de nsCaRevocationUrl (en rouge) afin de mettre la vôtre à la place : c'est l'adresse à laquelle les utilisateurs pourront se référer pour vérifier la liste de révocation de vos certificats.
Maintenant, il faut créer un répertoire pour accueillir les copies des certificats que l'on va signer afin de pouvoir facilement les trouver pour les révoquer en cas de besoin, un fichier pour accueillir les numéros de série et enfin un autre fichier pour y inscrire l'index de nos certificats signés :
# mkdir signed-keys && echo "01" > conf/serial && touch conf/index
Et voilà ! Nous sommes désormais une Autorité de Certification Racine à part entière même si bien évidemment non reconnue par les autres. Du coup, nous allons pouvoir signer les CSR qu'on voudra bien nous soumettre et ce, de la manière suivante : postulons qu'un tiers nous a fourni une CSR nommée request.csr en nous demandant de la signer. Nous allons d'abord nous assurer de l'exactitude des informations qu'elle contient :
# openssl req -in request.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=FR, ST=PACA, L=Marseille, O=MaCompagnie SA, CN=www.domaine.tld/emailAddress=adresse@domaine.tld
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:d9:58:b4:ca:b5:0e:8b:86:f7:8c:16:7f:c6:a4:
74:90:cb:66:09:b6:a7:4d:e5:a1:d4:2e:cb:98:dc:
10:72:a0:9c:42:78:24:17:82:2c:0b:ff:d6:ea:67:
76:c7:60:01:ea:c7:cd:31:12:24:b4:c5:9d:02:09:
0a:d9:2b:f2:bd
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
a6:e6:00:9c:f7:9e:20:08:b7:5c:4d:d4:32:e4:cb:0c:69:d2:
ad:19:f9:de:7c:9f:e1:76:05:a9:59:3e:05:6d:8b:3c:69:a2:
e3:8e:fe:e6:8b:a1:3f:a9:36:6a:80:da:c1:bb:5d:71:b3:63:
df:d4:17:6c:a3:9d:2a:62:3f:ff
La partie qui nous intéresse est en rouge dans l'exemple ci-dessus. Il faut être absolument certain que la personne qui demande le certificat est bien celle qui possède domaine.tld (il faut bien sûr vérifier aussi les autres critères, mais celui-ci est le plus important dans la mesure où c'est celui qui va être vérifié par le navigateur Web du client). Si nous sommes satisfaits des détails fournis et d'accord pour signer la requête, nous procédons alors comme suit :
# openssl ca -batch -config root.cnf -in request.csr -out request.cert
Using configuration from conf/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Dec 9 18:29:33 2011 GMT
Not After : Dec 9 18:29:33 2012 GMT
Subject:
countryName = FR
stateOrProvinceName = PACA
organizationName = MaCompagnie SA
commonName = www.domaine.tld
emailAddress = adresse@domaine.tld
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
4B:26:25:75:EE:74:63:2D:B5:07:E7:92:9F:B1:85:F6:B7:7A:78:24
X509v3 Authority Key Identifier:
keyid:D5:FE:57:B9:E3:C2:6F:95:7C:29:8D:77:12:D7:94:09:43:D6:2C:52
DirName:/C=FR/ST=Ile-de-France/L=Paris/O=MaCompagnie SA/CN=MaCompagnie Root CA/emailAddress=adresse@domaine.tld
serial:98:D7:B8:5A:5A:91:42:0F
Netscape CA Revocation Url:
https://www.doamine.tld/exemple-ca-crl.pem
Certificate is to be certified until Apr 8 18:29:33 2007 GMT (365 days)
Write out database with 1 new entries
Data Base Updated
Après cette opération, nous nous retrouvons avec un certificat request.cert, certificat signé par nous et que nous pouvons renvoyer au demandeur. Si nous avons besoin de révoquer la signature, nous pouvons la retrouver dans signed-keys/01.pem. Par ailleurs, conf/serial a été incrémenté de 1 et conf/index a été mis a jour pour inclure les caractéristiques du nouveau certificat.
Pour pouvoir révoquer une clef, nous devons retourner une dernière fois dans notre fichier de configuration de OpenSSL :
# vi conf/openssl.cnf
On y ajoute :
[ crl_ext ] authorityKeyIdentifier=keyid:always,issuer:always
Pour révoquer une clef :
# openssl ca -config conf/openssl.cnf -revoke request.cert
qui donne :
Using configuration from conf/openssl.cnf Revoking Certificate 01. Data Base Updated
Ensuite, on génère la liste de révocation (CRL) :
# openssl ca -config conf/openssl.cnf -gencrl -out exemple-ca-crl.pem
Enfin, on place cette liste à l'endroit indiqué précédemment (https://domaine.tld/exemple-ca-crl.pem) afin que les clients puissent être avertis de la révocation.
Ça y est ! Nous somme notre propre Root CA et pouvons signer des certificats et les révoquer. Une dernière petite opération peut consister à installer notre certificat racine dans l'infrastructure CA de notre système :
# cp public/root.pem /usr/share/ca-certificates/MaCompagnie-SA.crt # echo MaCompagnie-SA.crt >> /etc/ca-certificates.conf # update-ca-certificates
Et voilà ! Y'a plus qu'à la former cette foutue chaîne de confiance ! En commençant par informer les visiteurs de vos sites et à leur demander de vous faire confiance.
Read MoreRécupérer les clefs GPG des dépôts sur Ubuntu quand on est derrière un pare-feu
Voici le tableau : vous êtes dans votre chambre de cité U, ou peut-être au bureau, et vous tombez sur un joli PPA que vous désirez ajouter illico aux sources de votre Ubuntu. Pas de problème, vous dites-vous in petto : on ouvre un terminal et
$ sudo add-apt-repository ppa:freetuxtv/freetuxtv
Et là, PAF ! Ça ne marche pas, la connexion au serveur de clefs timeout lamentablement. En cause, le pare-feu de votre université ou entreprise qui, faisant son boulot, bloque systématiquement les connexions initiées vers des ports inconnus comme le port 11371, généralement utilisé par les serveurs de clefs.
Heureusement, Anthony, un étudiant de Durham, a trouvé une petite astuce qui va nous permettre de faire passer les requêtes de clefs GPG par le port 80 qui, contrairement au 11371, a très peu de chances d'être bloqué par le pare-feu derrière lequel vous vous connectez. Il a remarqué que la commande add-apt-repository est écrite en python, ce qui la rend très facilement éditable. En suivant la structure des importations, il a trouvé le fichier responsable de la récupération des clefs GPG des dépôts. Voici donc la marche à suivre :
– Éditez le fichier ppa.py qui se trouve dans le répertoire /usr/lib/python2.6/dist-packages/softwareproperties/ en faisant par exemple Alt+F2 puis en entrant
gksudo gedit /usr/lib/python2.6/dist-packages/softwareproperties/ppa.py
sans oublier de valider, et de taper votre mot de passe à l'invite.
– Ceci fait, trouvez dans le fichier la ligne n°88 et changez « keyserver.ubuntu.com » en « hkp://keyserver.ubuntu.com:80 ». Cela donne
res = subprocess.call(
["apt-key", "adv", "--keyserver", "keyserver.ubuntu.com",
"--recv", signing_key_fingerprint[0]])
qui devient
res = subprocess.call(
["apt-key", "adv", "--keyserver", "hkp://keyserver.ubuntu.com:80",
"--recv", signing_key_fingerprint[0]])
Enregistrez, et voilà ! La commande add-apt-repository utilisera désormais le port 80 pour récupérer les clefs des dépôts, et vous pourrez ajouter de nouveaux PPA en toute sérénité.
Read MoreModifier la police d'affichage de votre CMS ou de votre site Internet
Que l'on utilise un système de gestion de contenu (CMS) tel que WordPress, Drupal, Spip, Dotclear, etc. ou que l'on monte soi-même ses pages Internet, la typographie utilisée a toujours son importance. D'ailleurs, on peut remarquer qu'il s'agit très souvent des quelques mêmes polices qui sont utilisées par l'écrasante majorité des sites Web (je ne parle pas, bien sûr, des sites utilisant un alphabet différent du nôtre qui disposent de leurs propres polices) : ??les familles Trebuchet, Trebuchet MS, Tahoma, Lucida Grande, Lucida Sans Unicode, Arial et Verdana de la faille générique sans-serif.
La large utilisation de ces polices provient d'un projet de Microsoft appelé « Core fonts for the Web » initié en 1996 et visant à standardiser l'utilisation des polices de caractères sur Internet, avec des familles de polices répondant à trois critères importants :
- être facilement lisibles sur un écran
- offrir une large gamme de caractères avec un nombre de familles de polices restreint
- supporter une internalisation exhaustive
Trois critères effectivement très importants pour assurer une lisibilité optimale et une large compatibilité.
De nos jours, il existe plusieurs solutions pour forcer l'utilisation d'une police donnée sur son site Web. Il est par ailleurs possible dans tout navigateur Internet digne de ce nom de choisir une police locale pour afficher tout site Internet ne faisant pas mention explicite de la police qu'il utilise, mais ce n'est pas ce qui nous intéresse ici.
Le nombre de sites Web utilisant une police disons inhabituelle va croissant. On peut d'ailleurs remarquer que certains font de mauvais choix, rendant la lecture et même parfois la navigation vectrices de sérieux maux de tête : ce n'est pas parce qu'une police est jolie qu'elle est lisible, et selon la méthode utilisée le navigateur de l'utilisateur qui vient se balader sur votre site peut ne pas l'afficher correctement.
Comment utiliser une police donnée de façon à ce que ça marche pour tous les utilisateurs (ou presque) alors ? Eh bien, il existe principalement deux méthodes :
– la méthode cufón : basée sur Javascript/JSON, je dirais que son plus gros avantage est aussi son plus gros inconvénient, car elle repose sur Javascript. D'un côté, cela assure une très grande compatibilité avec les différents navigateurs, d'un autre côté il est bien évident qu'il faut que le navigateur supporte le Javascript pour qu'elle fonctionne. Or, bien que cela soit le cas par défaut dans la grande majorité des cas, on peut très bien avoir envie ou besoin de désactiver cette fonctionnalité intégrée et là, adieu le support des polices ! Par ailleurs, selon le type de police utilisé, le nombre de glyphes voulu, etc. on peut vite se retrouver avec un script assez lourd à charger. Ce n'est pas la méthode que je vais aborder ici.
– la méthode CSS : là, pas de Javascript, il s'agit de spécifier dans ses feuilles de style la faille de police à utiliser. Seule contrainte : il faut lier la police à son site, que ce soit localement ou en utilisant un répertoire de polices disponible sur Internet. Cette méthode, qui est selon moi celle à privilégier est plus légère, plus simple à mettre ne place et plus flexible que la précédente. Par contre, d'aucuns navigateurs peu civilisés se font un malin plaisir de mal interpréter certaines propriétés CSS, voire de les zapper purement et simplement (suivez mon regard…). Malgré cela, et parce que c'est au navigateur de s'adapter à Internet et pas l'inverse, voici comment spécifier l'utilisation d'une police de caractères donnée dans votre CMS ou sur votre site :
Sur beaucoup de CMS, le thème utilisé peut permettre de spécifier une police particulière. Par exemple, il en va ainsi du thème Suffusion que j'utilise sur mon installation WordPress :
Si vous ne disposez pas de ce type de réglage ou si comme moi vous ne trouvez pas votre bonheur dans la liste proposée, sachez qu'il existe des répertoires de polices en ligne tels que Font Squirrel ou le tout récent Google Font Directory que nous pouvons utiliser pour ajouter la définition de notre police au thème de notre CMS ou à notre site Web :
Pour les CMS, il s'agit d'éditer le fichier d'en-tête du thème : header.php pour Worpress, head.html pour Spip, ?_head.html pour Dotclear, etc. et d'ajouter la ligne suivante :
<link href='http://fonts.googleapis.com/css?family=Ubuntu:regular,italic,bold' rel='stylesheet' type='text/css'>
Ici, j'utilise la police Ubuntu du répertoire de Google. Imaginons que je préfère faire appel à ma police localement et que j'utilise l'un des merveilleux kits @font-face fournis par Font Squirrel :
<link rel="stylesheet" href="ubuntustyle.css" type="text/css" charset="utf-8">
et le fichier ubuntustyle.css contiendra ceci :
@font-face {
font-family: 'UbuntuRegular';
src: url('Ubuntu-R-webfont.eot');
src: local('?'), url('Ubuntu-R-webfont.woff') format('woff'), url('Ubuntu-R-webfont.ttf') format('truetype'), url('Ubuntu-R-webfont.svg#webfont5QrTZHwg') format('svg');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'UbuntuItalic';
src: url('Ubuntu-I-webfont.eot');
src: local('?'), url('Ubuntu-I-webfont.woff') format('woff'), url('Ubuntu-I-webfont.ttf') format('truetype'), url('Ubuntu-I-webfont.svg#webfontwdgWd3TL') format('svg');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'UbuntuBold';
src: url('Ubuntu-B-webfont.eot');
src: local('?'), url('Ubuntu-B-webfont.woff') format('woff'), url('Ubuntu-B-webfont.ttf') format('truetype'), url('Ubuntu-B-webfont.svg#webfontCKhwRblf') format('svg');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'UbuntuBoldItalic';
src: url('Ubuntu-BI-webfont.eot');
src: local('?'), url('Ubuntu-BI-webfont.woff') format('woff'), url('Ubuntu-BI-webfont.ttf') format('truetype'), url('Ubuntu-BI-webfont.svg#webfontLmVyebAO') format('svg');
font-weight: normal;
font-style: normal;
}
Maintenant, il va falloir éditer les styles de notre CMS, c'est à dire très souvent le fichier style.css (WordPress et Dotclear) ou habillage.css (Spip), bref, le fichier de styles correspondant. Il va s'agir d'appliquer la nouvelle police aux éléments voulus, comme par exemple :
h1, h2, h3, h4, h5, h6 {
font-family: Ubuntu, Tahoma, Verdana, Arial, sans-serif;
line-height:130%;
}
body {
font-family: Ubuntu, Tahoma, Verdana, Arial, sans-serif;
line-height:130%;
}
ou encore
h1.fontface {
font: 60px/68px 'UbuntuRegular', Arial, sans-serif;
letter-spacing: 0;
}
p.style1 {
font: 18px/27px 'UbuntuRegular', Arial, sans-serif;
}
p.style2 {
font: 18px/27px 'UbuntuItalic', Arial, sans-serif;
}
p.style3 {
font: 18px/27px 'UbuntuBold', Arial, sans-serif;
}
p.style4 {
font: 18px/27px 'UbuntuBoldItalic', Arial, sans-serif;
}
Et voilà ! Il vous suffit de recharger vos pages pour apprécier la différence (et éventuellement de vider le cache si vous utilisez un système de cache).
Dans le cas où vous voulez appliquer cela à votre site web, la technique est la même. Si vous disposez d'un fichier d'en-tête qui s'applique à toutes les pages c'est exactement la même démarche. Si vous n'avez pas d'en-tête commun à toutes vos pages, voici un exemple de modèle de page intégrant votre police :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Font Face Demo</title>
<link rel="stylesheet" href="ubuntustyle.css" type="text/css" charset="utf-8">
<style type="text/css" media="screen">
h1.fontface {
font: 60px/68px 'UbuntuRegular', Arial, sans-serif;
letter-spacing: 0;
}
p.style1 {
font: 18px/27px 'UbuntuRegular', Arial, sans-serif;
}
p.style2 {
font: 18px/27px 'UbuntuItalic', Arial, sans-serif;
}
p.style3 {
font: 18px/27px 'UbuntuBold', Arial, sans-serif;
}
p.style4 {
font: 18px/27px 'UbuntuBoldItalic', Arial, sans-serif;
}
#container {
width: 800px;
margin-left: auto;
margin-right: auto;
}
</style>
</head>
Le contenu du fichier ubuntustyle.css sera le même que présenté plus haut.
Vous pouvez bien sûr utiliser le répertoire de polices de Google par exemple si vous ne voulez ou pouvez pas accéder à des copies locales de la police choisie. La ligne 6 est dans ce cas
<link href='http://fonts.googleapis.com/css?family=Ubuntu:regular,italic,bold' rel='stylesheet' type='text/css'>
Voici en substance comment intégrer une police de votre choix dans votre site Web ou votre CMS. Gardez quand même à l'esprit que la typographie du Web est un sujet vaste et complexe et que le choix d'une police d'affichage ne doit en aucun cas se faire à la légère. Évitez d'utiliser des familles de polices trop exotiques qui risqueraient de rendre votre site inintelligible, une police se doit d'être lisible avant d'être jolie, les deux n'allant pas toujours de pair, loin s'en faut !
