Création et ajout d’un certificat gratuit StartSSL à Nginx

J’ai longtemps utilisé des certificats auto-signés pour mes connexions SSL/TLS, bien qu’un tel certificat assure le cryptage de la liaison, elle n’assure en aucun cas la validité de celui-ci. Lorsque c’est moi qui accède à un de mes sites, aucun problème (je peux encore me faire confiance je pense ^.^), mais quid des personnes tiers utilisant mes services? Elles ne peuvent se fier qu’à mes paroles. De plus un certificat auto-signé n’étant pas reconnu par les navigateurs, ceux-ci affichent cette page flashy indiquant les dangers d’accéder à un tel site.

D’un autre coté, un certificat délivré par une autorité compétente a un prix (plus ou moins variable). La solution intermédiaire est offerte par StartSSL, une société qui possède une offre gratuite de certificat SSL appelée Class 1 SSL. C’est un vrai certificat, certe basique et pour une utilisation personnelle, mais reconnu par les navigateurs, donc plus de page d’avertissement de ceux-ci avant de naviguer sur un site sécurisé. Celui-ci est gratuit, avec toutes vos informations d’identité, mais celles-ci ne sont pas vérifiées par StartSSL, donc c’est certainement un point délicat dans le cas d’un site d’e-commerce par exemple. Mais pour simplement sécuriser des pages d’administration, un back-office, c’est amplement suffisant.

Voici décrite ci-dessous la procédure de création et mise en place d’un certificat SSL pour Nginx.

Continuer la lecture de « Création et ajout d’un certificat gratuit StartSSL à Nginx »

Bug de Chrome v33 affectant les polices web

Depuis quelques jours je bataille avec mon thème Koken sur fabienamann.photography, les polices web (@font-face) n’apparaissent pas sous Chrome, jusqu’au moment où le texte en question est survolé ou cliqué par la souris. Problème jamais rencontré avant, j’avoue m’être senti démuni jusqu’à ce que l’équipe de Koken publie ce message, relatant un réel bug de Chrome 33. Le site Adobe Typekit en parle aussi.

J’espère que ce problème va être rapidement résolu avec la nouvelle version de Chrome. En attendant, je redirige via javascript les user agents estampillés « Chrome » vers une feuille de style sans polices web.

<script type="text/javascript">
if( /Chrome|Android|AppleWebKit|webOS|iPhone|iPad|iPod/i.test(navigator.userAgent) ) {
	document.write('<koken:asset file="css/settings_chrome.css" />');
} else {
	document.write('<koken:asset file="css/settings.css" />');
}
</script>

Note 04/03/2014 : Mise-à-jour de Chrome en Version 33.0.1750.146 m aujourd’hui, le problème reste le même.

Problème Zend_Session avec Google Chrome

J’ai rencontré un étrange problème avec les sessions du framework Zend et Google Chrome uniquement. Celles-ci ne sont tout simplement pas enregistrées. C’est un réel problème surtout avec l’utilisation de Zend_Auth car aussitôt que l’utilisateur passe le formulaire de login, celui-ci se retrouve déconnecté.

Le problème est beaucoup mentionné sur le web, avec des solutions dans tous les sens, dont une qui semble farfelue mais qui a résolu ce problème pour mes applications : ajouter une favicon.ico à la racine du site.

heard like a missing favicon.ico. chrome makes a new thread for requesting the favicon.ico. so if you handle 404 requests in a way with updating a session-cookie you will get a new session-id and your visible browser tab session has an other session than the « favicon » request! check your serverlogs and 404 handling.

Source : ZF Issue tracker