diff --git a/README.SSL b/README.SSL
new file mode 100644
index 0000000..fe81e99
--- /dev/null
+++ b/README.SSL
@@ -0,0 +1,46 @@
+To use authentic with SSL authentication your must configure Apache to do so.
+Here is an example of an Apache virtual host to use SSL client authentication:
+
+
+ServerName authentic.localhost
+Include /home/bdauvergne/wd/authentic-apache2.conf
+
+
+
+ServerName authentic.localhost
+LogLevel debug
+Include /home/bdauvergne/wd/authentic-apache2.conf
+SSLEngine on
+SSLCertificateFile /etc/apache2/certificates/localhost-wildcard.pem
+SSLVerifyClient none
+
+
+SSLVerifyClient optional_no_ca
+SSLOptions +StdEnvVars +ExportCertData
+
+
+
+SSLVerifyClient optional_no_ca
+SSLOptions +StdEnvVars +ExportCertData
+
+
+
+As you can see we do not force SSL client verification on the full site, so as
+to permit other kind of authentications without spurious dialog asking you for
+a certificate. We could use «SSLVerifyClient optional» on the full site but it
+would ask even user logging in with a password for a certificate (they can
+still select the cancel button, bit it stil waste their time). The other
+problem with «optional» and «require» value for SSLVerifyClient is that they do
+not work with certificate coming from an unknown CA or self-signed. These kind
+of certificate are still a strong authentication for any user, stronger than a
+shared secret sent in the clear.
+
+A current problem is that authentic do not generate a new cookie when
+authenticating with ssl and do not set it with the 'secure' flag that would
+prevent the navigator to release upon a not secured plain HTTP connection.
+
+Another problem is that we do not use the SSL session_id as a persistent cookie
+instead of a simple HTTP cookie, so an attacker can still do a MITM attack
+after the authentication. If the user is stupid enough to accet an hijacked SSL
+session and a clik throught the warning of the navigator, then the attacker can
+steal the HTTP secure cookie.