oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: ssl

OpenVPN roadwarrior (client windows)

Reading time: 4 – 6 minutes

Com us comentava al meu anterior article OpenVPN roadwarrior (server i client linux) també podem tenir un roadwarrior de la nostre VPN funcionant amb windows. Així que us descriuré breument com configurar aquest client configuració que és pràcticament idèntica a la del client linux.

El primer que hem de fer és clar, és baixar el paquet de l’openVPN per windows, el podeu trobar a la web de l’openVPN GUI for Windows. Després de descarregar-lo el podeu instal·lar on més us agradi un cop fet això comença la part interessant.

NOTA: si llegiu la documentació de l’openVPN per windows veureu que no he col·locat els fitxers de configuració a les direccions on ell espera trobar-les. I tampoc uso la propietat de servei de windows que pot tenir el programa. Però si ho voleu fer com ‘deu mana’ només cal modificar les rutes i treballar amb el servei de windows encomptes del meu script. Però jo he preferit fer-ho així de cara a tenir un control més personal del programa. Odio la transaparència del windows, prefereixo el meu sistema. Tot són gustos.

NOTA II: els mac també tenen un client d’openVPN anomenat Tunnelblick GUI for mac OS X. Però no tinc el gust de disposar d’un mac per provar i explicar-vos com va, us haureu de conformar amb les instruccions de la seva pàgina web.

Certificiat client

Aquesta part és igual que en linux, o sigui, que podeu mirar el post que us comentava més amunt i sabreu com es fa. Un cop tinguem el certificat client i la clau privada, copiem aquests dos fitxers juntament amb el ‘root CA’ a una carpeta de windows. Jo el que he fet és crear-me una carpeta que es diu openvpn a l’escriptori i dins he creat el directori certs, on hi he copiat els tres fitxers.

Configuració del client

Dins de la carpeta openvpn que comentava dins del punt anterior he creat un fitxer de configuració que es diu local.conf amb el següent contingut:

client
verb 1
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca ./certs/cacert.pem
cert ./certs/vpn-clientwin-cert.pem
key  ./certs/vpn-clientwin-key.pem

Com podeu veure el fitxer és pràcticament identic al de linux, només li he baixat el nivell de debug (verb 1) perquè aquí la sortida de logs es farà per consola i si pugem molt el nivell de debug ens ompla de bassura la consola.

Configuració interficie TAP/Win-32

Després d’instal·lar el paquet d’openvpn per win veureu que teniu una nova interficie de xarxa:

interficie.png

Aquesta interficie com podeu veure l’he renombra i l’he anomenat tun al fitxer de configuració que heu vist més amunt també uso la interficie tun i no la tap que és el nom del driver de l’interficie. La veritat no sé si hi té molt a veure això però havia tingut alguns problemes al configurar i al final m’ha quedat tal com veieu funciona.

Cal que tinguem la interficie configurada en mode DHCP, per tal de que agafi la IP de túnel automàticament:

configuracio.png

Script de llençament

Finalment el que m’he fet és un petit script (.bat) per llençar la VPN l’he anomenat vpn.bat i el contingut és tan senzill com:

cd "H:\Documents and Settings\Oriol\Escritorio\openvpn"
openvpn --config local.conf

Col·locar-me a la carpeta on hi ha tots els fitxers i després llençar l’openvpn informant-lo del fitxer de configuració que ha d’usar. És importnat indicar la carpeta de treball així el fitxer de configuració com podeu veure usa direccions relatives per referir-se als certificats. Molt més senzill que no pas haver d’escriure el ‘peazo’ directori absolut.

Depuració i proves d’ús

Aquí podeu fer les mateixes proes que amb el linux, també veureu que la interficie tun té el ‘cable de xarxa desconnectat’ fins que no es connecta l’VPN que passa a estar en mode ‘connectat’. Si feu un ipconfig /all des de la consola del windows també podreu veure la interficie tun amb la IP de túnel un cop connectada i si feu un route print les rutes estàtiques que li ha assignat el servidor de la VPN al crear-se la mateixa. Recordeu que això el servidor ho feia a través de la comanda push.

OpenVPN roadwarrior (server i client linux)

Reading time: 7 – 12 minutes

Doncs ja fa temps que sóc usuari de l’OpenVPN per mi un dels millors softwares per montar VPNs i pel que sembla no sóc l’únic, ja que a newsforge també es pot llegir un article que defensa el mateix: SSL VPNs and OpenVPN: A lot of lies and a shred of truth. Doncs bé fer un enllaç LAN2LAN ho podeu fer amb molt pocs segons, jo diria que amb menys d’1min. A més permet tan montar-les per tcp, com per udp, a més de passar per sobre de HTTP proxies d’això ja en parlaré en un altre article.

El que vull explicar aquí és com he configurat l’OpenVPN per poder connectar-me des de qualsevol lloc a la xarxa de casa (i d’altres xarxes que ara no venen al cas). L’autenticació i xifrat de l’enllaç el faré amb SSL/TLS. Així doncs quasi tot el que vaig explicar sobre CAs a l’article: HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A. ho podrem aplicar aquí.

L’esquema del que anem a montar el podeu veure en el següent gràfic:

Certificats

Així doncs, anem a resumir el tema dels certificats, com que tenim un servidor i un client, hem de generar el certificat pel servidor i pel client, no cal generar el CA, perquè ja en tenim un de l’article comentat. Així que ens col·loquem al directori ~/CA i creem els 3 fitxers tal i com indica l’article al que ens referim.

Ara tindrem els 3 fitxers de rigor:

newreq.pem -> petició de certificat que fem al CA
newcert.pem -> el certificat que ens torna el CA, després de signar la nostre petició de certificat
newkey.pem -> la clau privada del nostre certificat

Només afegir un comentari: mentre creem els fitxers comentats ens demani el ‘Common Name’ podeu posar algún nom representatiu ara no estem lligats a un nom de domini com en l’article en el que ens basem per crear els certificats. Per tal d’organitzar-nos el que farem és renombrar aquests fitxers amb els següents noms:

newcert.pem -> vpn-server-cert.pem
newkey.pem -> vpn-server-key.pem

La petició de certificat la podem borrar si volem. No la farem servir. Per completar els fitxers que ens fan falta per montar el servidor només cal crear el fitxer de paràmetres Diffie-Hellman. Escencialment ens ajudarà a establir VPNs segures en canals no segurs mentre s’intercanvien les claus simètriques que s’usaran per fer la VPN. Recordeu que les claus assimètriques (certificats que usem) només es fan servir com a mitja per establir un canal segur per on intercanviar una clau simètrica molt més ràpida de xifrar/desxifrar pels extrems que ens permetran mantenir un canal segur i el més ràpid possible.

Bé doncs creem aquest fitxer de paràmetres Diffie-Hellman: (dh1024.pem)

openssl dhparam -out dh1024.pem 1024

Jo només l’he fet de 1024bits però el podeu fer tan segur com volgueu 2048, 4096 o fins on tingueu ganes d’arribar. Jo he preferit no carregar els sistemes amb claus inútilment llargues pel tipus de seguretat que necessito. Bé doncs, ara només cal que creem els certificats del client tal i com hem creat els del servidor i com sempre us recomano canviar-li els noms al nou certificat, jo faré els següents canvis de nom:

newcert.pem -> vpn-client-cert.pem
newkey.pem -> vpn-client-key.pem

NOTA: Si voleu tenir més d’un client que es connecti de forma simultànea a l’VPN heu de crear un certificat per cada client.

Fitxer de configuració del servidor OpenVPN

Ara que ja tenim els certificats apunt els copio al servidor al directori /etc/openvpn/roadwarrior/certs. Anem a veure que hem de fer per preparar el fitxer de configuració, que en Gentoo va a /etc/openvpn/roadwarrior, al fitxer l’anomeno local.conf:

verb 5
status /var/log/openvpn-status.log
user nobody
group nogroup
persist-key
persist-tun
local 2.2.2.2
port 443
proto tcp-server
dev tun
comp-lzo
ca   /etc/openvpn/roadwarrior/certs/cacert.pem
cert /etc/openvpn/roadwarrior/certs/vpn-server-cert.pem
key  /etc/openvpn/roadwarrior/certs/vpn-server-key.pem
dh   /etc/openvpn/roadwarrior/certs/dh1024.pem
server 10.0.1.0 255.255.255.252
keepalive 10 120
push "route 10.0.0.0 255.255.255.0"

Si anem per ordre, a l’inici l’únic que fem és dir-li el nivell de debug que volem que es guardi i a quin fitxer. Després definim que el procés openvpn que tindrem corrent al sistema no tingui privilegis sobre el linux (nobody:nogroup). La part on comencem a tenir informació interessant és on ens indica amb la comanda local quina és la IP del firewall que esta escoltant peticions i ens diu que ho fa pel port 443 i sobre protocol TCP. Pot semblar una mica raro que escolti en un port pensat per ser usat per HTTPs però tinc els meus motius, de totes formes si no us agrada el port el canvieu. En un altre article que parlaré de com montar VPNs sobre HTTP proxies explicaré el perquè del port 443. Després li diem amb quina interficie de túnel treballarem i que usarem compresió per les dades que hi passin.

Arribem a la part de certificats on com veieu usem tots els fitxers que em creat anteriorment i el cacert.perm que és el certificat del ‘root CA’ que varem crear a l’article al que em refereixo tota l’estona. A les últimes tres línies el més destacat és que li diem de quin rang han de ser les IPs de la interficie de túnel, això ho fem amb la comanda server i després amb la comanda push llencem una ruta estàtica que li dirà al client com arribar a la LAN que tenim connectada a l’interior de firewall.

Si ara llenço el dimoni de l’OpenVPN (/etc/init.d/openvpn start) puc veure com el port 443 de la interficie pública esta escoltant les connexions que li arriben això ho podeu mirar amb un netstat -lpn.

Configuració del client

Primer comentar que el fitxer de configuració estarà guardat a /etc/openvpn/casa/ amb el nom local.conf i els certificats de client els copiem a /etc/openvpn/casa/certs/, anem a donar un cop d’ull al fitxer de configuració:

client
verb 5
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca /etc/openvpn/casa/certs/cacert.pem
cert /etc/openvpn/casa/certs/vpn-client-cert.pem
key  /etc/openvpn/casa/certs/vpn-client-key.pem

Com podeu comprovar la configuració del client és mínima, la part més important és la que amb la comanda remote indiquem quina és la IP pública i el port on hi ha el servei que ens ofereix la VPN. Fixeu-vos amb la comanda nobind on li diem que el client no ha d’estar escoltant a cap port, només obrir una connexió contra el servidor. Indiquem quins són els fitxers a usar pel certificat de client i el certificat de la ‘root CA’ i llestos, ja tenim el client a punt.

Per llençar el client, podeu igual que al servidor llençar la comanda /etc/init.d/openvpn start.

TCP vs UDP

Com podeu veure he montat la VPN sobre TCP però també es pot montar sobre UDP, és tan senzill com canviar la comanda proto tcp-server del servidor i proto tcp-client del client, per la comanda proto udp. Per traspassar alguns firewalls i per montar VPNs darrera de NATs sense redirigir ports és molt útil poder-la montar en NAT, ja us explicaré com es pot fer tot això amb un altre article.

Com ja he comentat abans si no us agrada el port 443, també es pot canviar pel que volgueu, no sé si a nivell de IANA es recomana usar algún port en concret per aquest tipus d’VPNs.

Depurar

Per veure quins són els missatges que treu el servidor ho podeu fer al fitxer que indica el propi fitxer de configuració, o sigui, /var/log/openvpn-status.log. Per veure els missatges del client podeu mirar el vostre fitxer de log’s general del sistema sovint: /etc/log/messages.

Si alguna cosa no us funciona us recomano que repasseu tots els passos comentats i que mireu els enllaços de les pàgines en que jo m’he basat per fer la meva configuració.

La prova

Com és lògic la prova de foc està en des del client fer un ping a una IP privada de la intranet de darrera el firewall, per exemple, si 10.0.0.1 és un server de la xarxa 10.0.0.0/24 doncs des del portatil fent ping 10.0.0.1 aquest ens hauria de tornar i si fem un traceroute -n 10.0.0.1 només hauria d’haver-hi dos salts, el firewall i el server destí. Perquè tota la comunicació va per dins el túnel i els salts que es fan per internet són transparents des de dintre el túnel.

Enllaços

Webs d’on he tret la informació per montar tot això:

HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A.

Reading time: 12 – 20 minutes

Com podeu veure aquest post té un parell de títols i suposo que seria molt senzill tenir-ne molts més. Així doncs intentaré descriure la idea del que després explicaré. El que pretenc fer parlant sense tecnisismes és disposar d’un servidor web que només sigui accesible de forma irrefutable i segura pels clients (navegadors) que nosaltres permetem. Això és útil per exemple per bancs, institucions, etc. tot i que en el meu cas és simplement per donar serveis via web als que només tingui accés gent controlada.

key.jpg

Per tal de montar això el que hem de fer és primer de tot montar una entitat de certificació, a la que anomenarem CA (Certifcate Authority). Això ens permetrà emetre tans certificats com volguem tan per servidors com per clients. De fet, perquè això es reconegui publicament només ens caldria que els certificats es signessin per una SA (Signing Authority) o autoritat de confiança. Perquè sapigueu de què parlo alguns exemples d’autoritats d’aquest tipus són: Baltimore, RSA, VeriSign i Thawte. De fet, si volem nosaltres mateixos podem fer d’SA el que no tindrem és la confiança de tercers, ja que no ens reconeixeran com a TA (Trust Authority). Però pel nostre exemple no ens cal així doncs nosaltres mateixos ens ho farem tot.

De fet, tota aquesta història de les entitats de certificació és molt més complexe, però nosaltres només arribarem fins on ens interessa. Intentant simplificar al màxim. Tampoc cal que ens montem una PKI (Public key infrastructure) professional per treballar amb algo tan senzillet. Així doncs, ja tenim clar que hem de montar una CA (root CA) que emetrà emetrà certificats signats per ella mateixa (self-signed certificate). Aquests certificats podràn ser usats per servidors i clients. Així doncs, si montem un servidor que usi aquest certificat podem fer que aquest requereixi que els clients disposin d’un certificat en mode client sinó no podran accedir al servei oferit.

Pel cas que ens interessa el que farem és montar un servidor web, Apache concretament, que només podrà ser accedit pels clients (firefox, netscape, MSIE, etc) que disposin del certificat corresponent.

Què necessitem per montar la CA?

Només cal que tingueu instal·lat el OpenSSL, jo com sempre uso Gentoo i el paquet que he usat és dev-libs/openssl-0.9.7e-r1. El fitxer de configuració més important d’aquest paquet està a /etc/ssl/openssl.cnf. Jo l’he modificat conretament on diu default_days = 365 he canviat el 365 per 3650 així els meus certificats encomptes de ser vigents durant un any seràn vigents durant 10 anys. Si voleu això també es pot alterar a través de la línia de comandes al llençar l’script CA.pl amb el paràmetre -days.

Com ja vaig comentar a l’article: Xarxa Wifi Segura: freeRadius + WRT54G = 802.1x (WPA-radius EAP/TLS), on també s’havia de montar una entitat de certificació la distribució gentoo no instal·la el fitxer CA.pl per defecte i pot ser que no el troveu pel vostre sistema després d’instal·lar el openSSL. Així doncs, jo el que he fet és descomprimir el paquet d’openssl i truere el fitxer directament d’allà i després me l’he copiat a un directori on treballaré a partir d’ara: ~/CA.

Creem la C.A. arrel (root CA)

Un cop dins de ~/CA per generar el certificat de l’entitat arrel (root CA) només cal que feu: perl CA.pl -newca.

$ perl CA.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 1024 bit RSA private key
......................++++++
.............++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:BCN
Locality Name (eg, city) []:BCN
Organization Name (eg, company) [Internet Widgits Pty Ltd]:example CA authority
Organizational Unit Name (eg, section) []:example
Common Name (eg, YOUR name) []:example CA
Email Address []:example@example.com

Veureu que es crea un directori que es diu demoCA i dintre hi ha el fitxer cacert.pem que és el certificat de la nostre root CA.

Emetem un certificat amb la nostre root CA

Primer el que fem és una petició de certificat (request): perl CA.pl -newreq.

$ perl CA.pl -newreq
Generating a 1024 bit RSA private key
...................++++++
.................................................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:BCN
Locality Name (eg, city) []:BCN
Organization Name (eg, company) [Internet Widgits Pty Ltd]:example company
Organizational Unit Name (eg, section) []:example e-comerce department
Common Name (eg, YOUR name) []:www.example.com
Email Address []:example@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem

Obtenim el fitxer: newreq.pem. Fixeu-vos que aquest certificat és pel servidor www.exemple.com. Si voleu emetre un certificat per qualsevol subdomini del domini exmemple.com, podeu posar a ‘Common Name’ el següent *.exemple.com. El que no he provat és posar * a veure si així funciona per qualsevol domini. Tot i que jo diria que no ha de funcionar, sinó el certificat no garintiria que el servidor és qui diu ser.

Signem el certificat emès

Aquest pas és el que hauriem de demanar a la entitat de confiança (TA) la qual després d’enviar-li el nostre certificat ens el tornaria signat (SA). Però que nosaltres som com el ‘joan palom’ (jo me lo guis jo me lo com) doncs ens ho farem nosaltres mateixo amb l’ordre perl CA.pl -sign:

$ perl CA.pl -sign
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            82:9d:18:98:a7:25:24:7e
        Validity
            Not Before: Oct  1 10:50:03 2005 GMT
            Not After : Oct  1 10:50:03 2006 GMT
        Subject:
            countryName               = ES
            stateOrProvinceName       = BCN
            localityName              = BCN
            organizationName          = example company
            organizationalUnitName    = example e-comerce department
            commonName                = www.example.com
            emailAddress              = example@example.com
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                EE:8C:BC:6F:3D:3B:4D:82:56:24:BB:76:E8:39:F3:23:F3:BD:C9:BF
            X509v3 Authority Key Identifier:
                keyid:EE:71:7F:C0:71:39:F1:8A:70:B4:BC:BB:F0:48:B2:77:58:E4:F6:AE
                DirName:/C=ES/ST=BCN/L=BCN/O=example/OU=example/CN=example/emailAddress=example@example.com
                serial:82:9D:18:98:A7:25:24:7D
Certificate is to be certified until Oct  1 10:50:03 2006 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

Ara ja tenim signat el newreq.pem dins del fitxer newkey.pem. A continuació el que farem és extreure la clau privada que hi ha dins del fitxer newkey.pem:

$ openssl rsa < newreq.pem > newkey.pem
Enter pass phrase:
writing RSA key

A newkey.pem hi ha la clau privada del ‘request’.

Renombrem els fitxer per aclarir les coses

Per tal de simplificar una mica tots els conceptes és una bona idea renombrar els fitxers que hem generat:

newcert.pem -> server_cert.pem: certificat signat pel nostre servidor. Això ens permetrà després crear la clau del client.
newkey.pem -> server_key.pem: clau privada (xifrada) en format de texte pla necessaria pel certificat del servidor. La clau privada és la part secreta del certificat, hem d'evitar que tercers la puguin aconseguir.
newreq.pem -> server_req.pem: clau privada xifrada i la petició de certificat original.

Creem el certificat pel client en format pkcs12

Resulta que els nostres navegadors volen els certificats de client en un format que es diu pkcs12 (Personal Information Exchange Syntax Standard) així doncs som-hi:

# openssl pkcs12 -export -in server_cert.pem -inkey server_key.pem -out iestuff.p12
Enter Export Password:
Verifying - Enter Export Password:

Aquí també podria haver canviat el nom del fitxer on es guarda la clau i no posar-li iestuff.p12 com els exemples en que m’he basat, però la mandra és el que té. Bé doncs, ja tenim el nostre fitxer pkcs12: iestuff.p12.

Instal·lem el certificat a l’apache

No us ho creureu però he trigat més estona en fer això que en tota la resta i mira que és senzill, però he aprofitat per actualitzar el servidor i resulta que el nou paquet d’apache per gentoo funciona diferent que l’anterior i no trobava res de res. A partir d’ara parlaré doncs de com fer això en net-www/apache-2.0.54-r31. Però donaré un apunt per estalviar temps als que no useu gentoo.

L’apunt l’únic que s’ha de fer és posar els detalls necessaris perquè funcioni el vostre servidor apache amb SSL i dels fitxers de configuració d’apache només heu de modificar el ‘VirtualHost’ que necessitarà el certificat. Així doncs a partir d’ara el que toca és veure la destresa de cada un amb les infitintes ordres que té l’apache pels seu fitxer de configuració.

NOTA IMPORTANT PER TOTHOM: no oblideu que quan treballem amb un VirtualHost dins de l’espai de configuració del mateix cal user el paràmetre ServerName; doncs bé el que poseu aquí ha de coincidir al 100% amb el que posa al ‘Common Name’ del certificat que heu emès. A més, el vostre DNS ha de resoltre el mnemònic que hagiu usat amb la IP del servidor sinó no funcionarà, a més el nom ha de ser un registre de tipus A i no un CNAME dins la configuració del DNS.

Bé doncs en el paquet de gentoo que comentat el que he fet és modificar el fitxer de configuració del host SSL per defecte, això es fa al fitxer: /etc/apache2/modules.d/41_mod_ssl.default-vhost.conf. Per llençar l’apache amb el host SSL per defecte s’ha de tocar el /etc/conf.d/apache2 perquè es llenci amb les opcions: -D SSL i -D SSL_DEFAULT_VHOST. Amb això el fitxer de configuració 41_mod_ssl.default-vhost.conf passa a tenir validesa. Aqust fitxer l’he modificat ben poc només perquè apunti on he copiat els certificats.

Fixer 41_mod_ssl.default-vhost.conf:

<IfDefine SSL>
  <IfDefine SSL_DEFAULT_VHOST>
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot "/var/www/localhost/htdocs"
ServerName www.exemple.com
ServerAdmin root@localhost
ErrorLog logs/ssl_error_log
<IfModule mod_log_config.c>
        TransferLog logs/ssl_access_log
</IfModule>41_mod_ssl.default-vhost.conf
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/server_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/server_key.pem
SSLCACertificatePath /etc/apache2/ssl/
SSLCACertificateFile /etc/apache2/ssl/cacert.pem
SSLVerifyClient require
SSLVerifyDepth  2
	<Files ~ "\.(cgi|shtml|phtml|php?)$">
    SSLOptions +StdEnvVars
</Files>
	<Directory "/var/www/localhost/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
	<IfModule mod_setenvif.c>
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
</IfModule>
	<IfModule mod_log_config.c>
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</IfModule>
	<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
</IfModule>
	</VirtualHost>
	</IfModule>
	</IfDefine>
</IfDefine>

He tret els comentaris que porta el fitxer perquè no es fassi tan llarg. Però la part més important us la comento a continuació:

ServerName www.exemple.com
SSLCertificateFile /etc/apache2/ssl/server_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/server_key.pem
SSLCACertificatePath /etc/apache2/ssl/
SSLCACertificateFile /etc/apache2/ssl/cacert.pem
SSLVerifyClient require
SSLVerifyDepth  2

La primera línia és la nota que us he posat abans sobre el ServerName, o sigui, posar-lo igual que el ‘Common Name’ del certificat. El certificat signat del servidor SSLCertificateFile, la clau privada del certificat SSLCertificateKeyFile el directori on guardem les entitats de certificació arrel (root CA) SSLCACertificatePath /etc/apache2/ssl/ i el fitxer que conté el certificat de la nostre entitat de certificació arrel SSLCACertificateFile.

Les últimes dues línies són les més interessants: SSLVerifyClient indiquem si cal que el client tingui o no tingui certificat. En aquest cas requerim que el client tingui certificat per funcionar. Finalment a la última línia indiquem quina és la tolerància que donem als certificats que acceptem. És a dir, fins a quina profunditat confiem amb les entitats que poden haver emès aquest certificat. Diguem que és un tecnisisme d’herència entre entitats de confiança jo hi he posat un 2 però podeu posar-hi qualsevol número >1 i funcionarà sense problemes.

Configuració del client

Aquí només us comento com es fa amb el firefox, però amb el MSIE i el Netscape es fa quasi igual, segur que us en sortiu. Jo no només he afegit el certificat client que seria el normal sinó també el certificat de la entitat arrel (root CA) així el navegador no em pregunta cada vegada si ha de confiar amb el certificat que rep d’una root CA que no coneix.

Anem al menú Edit -> Preferences -> Advanced -> Manage Cerficates:

firefox1.png

Ara instal·lem el certificat client, anem a ‘Your Cerficates’ i premem ‘Import’ seleccionem el fitxer i importem el nostre certificat iestuff.p12:

firefox2.png

Per instal·lar el certificat del ‘root CA’ anem a la pestanya ‘Authorithies’ premem ‘Import’ i importem el fitxer cacert.pem:

firefox3.png

Conclusions

Sembla molt llarg tot el procés, però realment no ho és tan simplement que explicant sempre t’allargues més del que realment després has de fer a més he intentat ser força fidel en tot el que he fet en cada pas. Es podria haver simplificat molt més. No patiu per la part del servidor penseu que si us enganxeu el vostre problema és que coneixeu poc l’apache i d’això a tot arreu n’hi ha gent que en sap i de manuals en teniu per aburrir. Pel que fa el tema del client com podeu veure és molt senzill i si la resta esta bé funcionarà a la primera.

Enllaços

Per montar tot això he usat bàsicament dos sites que m’han ajudat moltíssim: