Jan 19

DHCP server for Windows 10

Reading time: 1 – 2 minutes

This is a super useful and simple tool, first of all, let me say thanks to Dani because I found the tool thanks to him. Very often I have the requirement to set up small virtual, real or hybrid networks using my laptop as a server and I had to boot a VM for getting a DHCP server simple to manage and powerful. Now, this is not required anymore because thanks to this tool I found a super small and flexible tool, I can set up all that I need using an INI file or just a wizard. It’s a pleasure and I don’t have to install anything if I don’t want, just a tray icon application is running for allowing me to give the service to my experimental networks.

Those projects that gain my commitment in a second: DHCP Server for Windows

Oct 27

Desaparegut… i petit review del portàtil, servidor i la vida en general

Reading time: 5 – 8 minutes

Tinc pendent parlar-vos de mil coses que he après, que he fet i que he tocat durant aquest munt de temps que no he pogut escriure al blog. En poques paraules he estat vivint a l’oficina des d’abans que sortís el sol fins que feia una bona estona que ja era amagat. Sort que el resultat final de tanta feina té una bona recompensa, un munt d’aplicacions per movilpoint que realment per primer cop a la vida em fan sentir orgullós de la feina feta.

Així doncs, ja no només ús he de parlar del meu nou portàtil sinó també del servidor HP que m’he comprat, un HP ProLiant ML110:

  • Dual Xeon 1.8GHz
  • 4Gb de RAM
  • 160Gb SATA

La idea és que faci de substitut a l’actual Celeron a 2.4GHz amb 1Gb de RAM i 1.3Tb de disc. Aquest el posaré com a firewall i hi instal·laré el pfSense. Que ja tinc a casa d’uns quants clients i a la feina i va molt bé.

Per altre banda, durant aquests dies he anat arrossegant dos portàtils el nou i el vell tot aprofitant cada un dels segons que tenia lliures per fer la migració del que tinc en el vell cap al nou.

Encara queden mil coses al portàtil nou per configurar però escencialment ja tinc el que necessito per treballar. Hi ha alguns detalls que no m’acaben de fer el pes però què hi farem. Em refereixo sobretot per com es comporta algún hardware amb linux, per exemple, si carrego el driver d’nvidia per les X‘s després no puc tornar a la consola. Això si la majoria de coses em tenen més que enamorat. No té nom veure la Gentoo compilant amb dues CPUs a 2.2GHz i 4Gb de RAM… això vola!!!! per no parlar de poder tenir: dos firefox, l’evolution, 2 màquines virtuals amb Ubuntu fent feina, el client de last.fm, l’OpenOffice, el ZendStudio i l’Eric4, la consola tot obert a la vegada i ni tan sols notar que la màquina perd una mica de velocitat. Ah! i encara tenir 1.5Gb de RAM lliures. Recomano que ho proveu.

Una altre cosa a la que no estava acostumat és a tenir una gràfica com deu mana. Concretament tinc una nVidia GeForce 8400M GS, ara mateix estic escribint aquest article amb una pantalla de 17″ conectada al portatil i amb un escriptori amb Xinerama. O sigui, dues pantalles fent d’escriptori una a 1280×800 (portàtil) i l’altre a 1280×1024 (externa) obviament amb 32bpp. Per si això fos poc ja m’he demanat dues pantalles Samsung de 22″ una que tindré a l’oficina i l’altre per casa, ambdues són idèntiques així podré tenir tot configurat igual a un lloc i a l’altre. O sigui, la pantalla externa a 1600×1080 i l’altre com la tinc ara.

Comentar que la targeta de so ha estat una mica difícil de configurar, no tan perquè no funcionés ràpidament. Sinó perquè no es reconeixia automàticament. Finalment he desactivat el suport ALSA del kernel i he instal·lat el driver extern concretamen la versió en desenvolupament. En Gentoo són els paquets media-sound/alsa-headers-9999 i media-sound/alsa-driver-9999, després fent un alsaconf i restaurant els volums tot a rutllat.

La resta de coses com la webcam, lesctor de targetes flash, comandament a distància i lector d’empremta digital encara no els he provat de configurar malgrat sé que han de funcionar. Per altre banda, la gràfica, el so, el disc dur amb turbo flash SATA, etc. funcionen molt bé.

Sobre la feina comentar que hem fet un parell de sistemes de distribució per dues pantalles amb Linux embedded que si tot segueix el seu curs han d’alimentar una xarxa de mil pantalles, tot i que de moment en proves només n’hi ha tres de funcionant i la cosa va molt bé. Perquè ús en feu una idea són unes pantalles que van a uns comerços i que mostren llistes de reproducció basades en imatges (JPG) i videos (MPG4).

Per altre banda, també hem fet un munt d’apliacions que treballen de la mà pel món dels kioskos. Realment espectacular: sistemes de creació de continguts, servidors d’aplicacions, players multimedia completament online amb cachés locals en el player, sistemes de monitorització de xarxa, estadístiques, PKI per control d’VPNs i mil històries més que algún dia hauré d’explicar a la web de l’empresa malgrat, això s’ha de reconeixer, que fa molta mandra documentar i més després d’acabar tanta feina.

La conseqüència de tot això…

ja ho heu vist, tinc l’estudi de casa fet un caos. Caixes apilades i papers sobre papers que s’acumulen. A veure si poc a poc vaig ordenant les coses. Però la veritat no tinc cap pressa, espero que això passi durant els propers mesos així ja vaig posant ordres al meu petit CPD i renovo una mica el hardware. A més, quan arribi la nova pantalla de 22″ la setmana que ve vull re-ordenar l’escriptori. Ja ús ho ensenyaré quan ho tingui montat, però la idea és aprofitar-me del Synergy i treballar amb 4 o 5 pantalles a la vegada, ja veurem com ho deixo al final.

Jul 18

Clonant una Ubuntu

Reading time: 3 – 4 minutes

Disposava d’un servidor en una màquina virtual d’VMWare que esta en producció i per tant, no era bona idea apagar-lo. La idea era montar una altre màquina física igual per posar-la en producció per quan la primera falli. Doncs bé, havia de montar una màquina igual que la de producció amb la mateixa configuració del servidor en producció. La cosa se m’ha allargat una mica malgrat els passos són simples. Bàsicament m’he trobat amb problemes tontos que per no estar habituat a usar Ubuntu m’han portat més temps del previst.

Per començar del host en producció aconseguim un llistat del paquets instal·lats, llencem la següent comanda des del directori i l’usari root:

dpkg --get-selections | grep -v deinstall > llista_paquets

A continuació ja podem fer tots els processos des de la màquina que anem a instal·lar. En la segona màquina he instal·lat una Ubuntu Server 6.06.1 LTS (Long Time Support) igual que en la primera, he fet una configuració de servidor normal (no LAMP) configurant el hardware adequat perquè tot funcioni. Un cop acabada la instal·lació:

# Copiem configuració del APT de producció al nou servidor
rsync -cavz root@ip_produccio:/etc/apt/ /etc/apt/
# Actualitzem repositori
apt-get update
# Actualizem paquets bàsics de la distribució
apt-get dist-upgrade
# Copiem llistat de fitxers de producció
rsync -cvz root@ip_produccio:/root/llista_paquets /root/
# Marquem paquets a instal·lar en local
dpkg --set-selections < llista_paquets
# Entrem al gestor de paquets dselect
dselect
# Ara premem la tecla 'I' i després 'intro' perquè comenci la
# descarrega i instal·lació de paquets
# Finalment premem la tecla 'Q' i 'intro'

En aquest punt ja tenim els mateixos paquets instal·lats en producció que en la nova màquina. Ara s’ha de copiar les configuracions de les aplicacions que tenim en marxa. La idea és copiar tot /etc i tot /var. Tot i que això s’ha de fer molt en compte i s’ha de depurar molt, per poder saber sempre si l’hem liat en algún moment. Ja que per exemple, no cal copiar tots els directoris de logs tot i que si estem en una LAN i no són molts megues tampoc passa res si ho copiem. El més crític, és no sobre-escriure fitxers com /etc/fstab que poden variar segons la arquitectura de les màquines. En el meu cas no calia tenir en compte gran cosa més, però penseu que hi ha aplicacions que tenen fitxers de configuració en llocs poc habituals i això també s’hauria de copiar. A més és vital que no oblideu que no només s’han de copiar els fitxers, sinó també els seus atributs, o sigui, permisos i propietaris.

Una bona idea per copiar el directori /etc és crear un fitxer amb la llista de fitxers i/o directoris que no volem copiar, en el meu cas: (exclude_list.txt)

/etc/fstab
/etc/modprobe.d
/etc/modutils

Després amb la següent comanda sincronitzem els fitxers i els seus permisos del servidor de producció al nou servidor:

rsync -cavz --delete --exclude-from=exclude_list.txt root@ip_publica:/etc/ /etc/

La resta de configuracions es poden copiar amb el mateix procés.

Nov 23

Script: entrar en un servidor protegit amb iptables

Reading time: 3 – 4 minutes

Un fenòmen molt humà i per tant habitual, quan estem configurant un firewall amb iptables contra un servidor remot al que no tenim accés, posem per cas que esta als EUA, és el de fer-nos fora a nosaltres mateixos al executar l’script que llença les regles de filtrat. Llavors podem reiniciar la màquina a través del panell de control que ens ofereix l’ISP, o qualsevol altre procediment. El problema esta en que si aquest script s’executa només iniciar la màquina en el rc.local o qualsevol altre procés d’arrencada serà impossible que ens autentiquem per SSH després de que arrenqui el servidor.

Però… com tots els que hem vist arrencar un servidor en linux sabem, entre crida el servidor SSH i es llença l’script de les regles del firewall, pot passar 1s (~aprox) segons el ràpid que sigui el servidor. Si fossim prou ràpids autenticant-nos a la màquina podriem llençar un procés que es llencés després de l’script de les iptables i aquest script ens podria tornar a donar accés a la màquina, per exemple, netejant les regles del firewall i canviant la política per defecte.

Doncs bé, després de provar de fer-ho a mà vaig arribar a la conclusió que malgrat haver fet un curs de mecanografia quan era petit, encara era massa lent i l’enllaç es tallava abans no pogués recuperar el control de la màquina. Així doncs, vaig decidir comprovar si la màquina disposava d’un llenguatge que s’anomena expect i que es basa en TCL/TK. Aquest llenguatge com ja he comentat algún cop al blog ens permet automatitzar processos intereactius. Així doncs, vaig fer-me aquest petit script:

#!/usr/bin/expect -f

spawn /usr/bin/ssh root@ip_del_servidor expect "ssword: $" { send "password_de_root\n" } expect "#" { send "echo \"sleep 30;iptables -F;iptables -P INPUT ACCEPT;iptables -P FORWARD ACCEPT;iptables -P OUTPUT ACCEPT\" > rest.sh \nchmod 700 rest.sh\nnohup ./rest.sh\nsleep 5\n./rest.sh" } interact

Fixeu-vos que és molt senzill, el que fa és connectar-se per SSH amb el servidor remot, enviar el password de root; després crea un script molt senzill que es guarda a rest.sh li dona permisos d’execusió i l’executa amb un nohup perquè si la nostre consola perd la connexió amb el servidor l’script no deixi d’executar-se. El contingut d’aquest petit script que es crea és tan senzill com esperar-se 30s perquè així s’assegura que la màquina ha acabat el procés d’arrencada i després neteja les regles del firewall i posa les polítiques en ACCEPT. Així doncs, ja podem entrar sense problemes.

Doncs bé amb això un ping que vigili quan s’ha aixecat la targeta de xarxa i després executant aquest script que us he posat aquí, jo el dimarts vaig aconseguir ressussitar un servidor remot al que no tenia accés físic, només forçant reboots a través del panell de control que em van facilitar. El senzill que hagués estat tenir una consola d’administració remota i tot llest amb un segon. Però suposo que la necessitat desperta l’enginy, no?

Jul 31

Sistema d’audio domèstic (MPD player)

Reading time: 5 – 8 minutes

La meva intenció no és fer un altre article súper tècnic amb fitxers de configuració i detalls molt tècnics. Malgrat es tracta de la descripció d’un projecte tècnic, no considero que tingui cap punt de dificultat, per tant, em centraré més en l’aspecte descriptiu i filosofic del que es preten aconseguir.

Doncs bé la idea és montar-me una mica millor sistema per escoltar música a casa, tan a l’estudi (on hi ha els PCs) com a la resta de la casa. Per això he fet un petit esquema del que he montat aquest cap de setmana.

mpd-schema.png

La idea és aprofitar que el servidor té targeta de so i disposa del repositori principal de música. El reproductor que li he instal·lat és una mica especial, s’anomena MPD (music player daemon). Bàsicament la gràcia que té és que funciona com a dimoni i que permet rebre comandes remotes a través d’un socket TCP. Per tant, podré controlar remotament el que esta sonant a través de programes client.

A més gràcies a jinzora un aplicatiu via web, puc consultar tota la música disponible amb tota la informació de la música del repositori i a través de la interficie puc enviar noves playlist o música sota demanada contra el servidor MPD. Realment és un aplicatiu impressionant, molt recomenable. Si no es disposa d’un servidor MPD també pot enviar la música a través d’streaming fins al player de l’usuari i si l’ample de banda no és massa bo permet fer transcoding en temps real.

Bé doncs, només amb això ja puc posar música des de qualsevol dispositiu que em permeti accedir a la interficie web del jinzora. Perquè si el programes en mode jukebox permet llençar la música directament contra l’MPD. A més aquestes cues de música a sonar no les manté jinzora sinó l’MPD així doncs quan connectem amb un client d’mpd podrem veure la canço que sona, la cua, fer pausa, parar la música, tocar el volum del servidor, etc.

A la sortida d’audio de la targeta de so del servidor hi he connectat la minicadena i quan vull a la sortida de la minicadena connecto el transmissor d’audio de Rimax, el que vaig comprar el gener de l’any passat (funciona per UHF a 800MHz). Així els altaveus (receptors) de la planta de baix també es posen a reproduir la música de l’estudi.

Ara aprofitant que tinc cobertura wifi per tota la casa, he configurat al nokia 770 un programa que es diu glurp, també disponible per PC. Es tracta d’un client d’MPD. És molt lleuger i ràpid, cal pensar que només fa de frontend i permet tenir les nostres llistes de reproducció al servidor, recuperar-les quan volguem i crear llistes noves de forma molt senzilla. Aquest client el tinc instal·lat també al portàtil, va molt bé.

Així doncs, amb quatre eines i una estona de paciència configurant i fent proves. Ja tinc el sistema d’audio més o menys decent. Obviament és molt millorable. De fet, la idea que porto al cap seria algo semblant a això:

Bàsicament es tracta d’ampliar les zones on hi ha altaveus sense fils, a més es tracta de col·locar un parell de mixers si pot ser digitals tan a l’estudi com al menjador. Per tal de poder controlar el volum de tot plegat de forma centralitzada. També m’agradaria començar a montar d’una vegada el media center del menjador. Amb el MPD amb un mirall del repositori montat a través d’openAFS i sincronitzat a través de wifi.

A més el mixer de l’estudi hauria de permetre capturar les sortides d’audio dels dos PCs, poden desviar el so cap a la minicadena o cap als headphones, així si la Daphne es posa a estudiar xinès no em molesta mentre jo escolto música o simplement treballo sense música. He vist que hi ha mixers d’aquests que s’anomenen matrix però no són controlats via soft, sinó a través d’una consola tipus comandament a distància amb una pantalleta. A veure si en trobo algún que m’ho permeti fer via soft.

Un tema pendent en el que encara no m’he posat és en suportar streaming des d’internet. De fet, no és res de l’altre món, però estava donant-li voltes en quines són les funcions que em podrien interessar en aquest sistema i la veritat no trobo quines, ja que últimament no escolto gran cosa per internet.

A més també li donava voltes a fer que els servidors MPD agafessin la música d’un servidor d’streaming intern (shoutcast) i així ambdos reproductors treurien el mateix so i tan a l’estudi com a baix se sentiria el mateix. Però tampoc ho he trobat massa important i per això no m’hi he liat.

Ara em queda pendent un altre article, que seria un article complementari a aquest, on us parlaré de productes comercials i altres ‘invents’ que permeten extendre aquesta idea que explico aquí. Però per avui ja he escrit prou… me’n vaig a treballar.

Oct 02

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: