Exploracin de Vulnerabilidades SSL Instel & Seguridad

1. Definicin. 1.1. Protocolo SSL: Referencias. http://tools.ietf.org/html/rfc2246 1.2 Verificacin de Certificados. Entidad verificadora de certificados (Verisign, OpenSSL). 1.3 Limitaciones del protocolo (bugs, vulnerabilidades, hbitos de usuarios, etc). 2. Exploracin de Vulnerabilidades (herramientas). 2.1 SSLStrip. 2.2 Ettercap (LAN Sniffer). 2.3 FireSheep (Extensin de Firefox). 3. Contramedidas. 3.1 Navegacin Segura. 3.2 Detectar Ataques MiTM con Ettercap.

1. Definicin.
Referencias: RFC 4346, reemplazada por RFC 5246, 5746, 5878 (estndard propuesto ); modificada por RFC 4366, 4680, 4681, 5746 (correcciones). El protocolo SSL es un sistema diseado y propuesto por Netscape Communications Corporation. Se encuentra en la pila OSI entre los niveles de TCP/IP y de los protocolos HTTP, FTP, SMTP, etc. Proporciona sus servicios de seguridad cifrando los datos intercambiados entre el servidor y el cliente con un algoritmo de cifrado simtrico, tpicamente el RC4 o IDEA, y cifrando la clave de sesin de RC4 o IDEA mediante un algoritmo de cifrado de clave pblica, tpicamente el RSA. La clave de sesin es la que se utiliza para cifrar los datos que vienen del y van al servidor seguro. Se genera una clave de sesin distinta para cada transaccin, lo cual permite que aunque sea reventada por un atacante en una transaccin dada, no sirva para descifrar futuras transacciones. MD5 se usa como algoritmo de hash. Proporciona cifrado de datos, autenticacin de servidores, integridad de mensajes y, opcionalmente, autenticacin de cliente para conexiones TCP/IP. Cuando el cliente pide al servidor seguro una comunicacin segura, el servidor abre un puerto cifrado, gestionado por un software llamado Protocolo SSL Record, situado encima de TCP. Ser el software de alto nivel, Protocolo SSL Handshake, quien utilice el Protocolo SSL Record y el puerto abierto para comunicarse de forma segura con el cliente.

El Protocolo SSL Handshake

Durante el protocolo SSL Handshake, el cliente y el servidor intercambian una serie de mensajes para negociar las mejoras de seguridad. Este protocolo sigue las siguientes seis fases (de manera muy resumida): La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos para mantener la intimidad y para la autenticacin. La fase de intercambio de claves, en la que intercambia informacin sobre las claves, de modo que al final ambas partes comparten una clave maestra. La fase de produccin de clave de sesin, que ser la usada para cifrar los datos intercambiados. La fase de verificacin del servidor, presente slo cuando se usa RSA como algoritmo de intercambio de claves, y sirve para que el cliente autentique al servidor. La fase de autenticacin del cliente, en la que el servidor solicita al cliente un certificado X.509 (si es necesaria la autenticacin de cliente). Por ltimo, la fase de fin, que indica que ya se puede comenzar la sesin segura.

El Protocolo SSL Record

El Protocolo SSL Record especifica la forma de encapsular los datos transmitidos y recibidos. La porcin de datos del protocolo tiene tres componentes:

MAC-DATA, el cdigo de autenticacin del mensaje. ACTUAL-DATA, los datos de aplicacin a transmitir. PADDING-DATA, los datos requeridos para rellenar el mensaje cuando se usa cifrado en bloque.

1.2 Verificacin de Certificados.

Aunque nuestros datos viajen cifrados por la Red, si los estamos enviando a (los recibimos de) un impostor, no saldremos mucho mejor parados. Se hace imprescindible el contar con un mecanismo que d fe de si un servidor seguro es quien creemos que es y podemos confiar en l a la hora de transmitirle nuestra informacin. La forma como se hace es mediante las Autoridades de Certificacin (AC), conocidas informalmente como notarios electrnicos, encargadas de autenticar a los participantes en transacciones y comunicaciones a travs de la Red. Su funcin es emitir certificados a los usuarios, de manera que se pueda estar seguro de que el interlocutor (cliente o servidor) es quien pretende ser, garantizando as la seguridad de las transacciones. El certificado de seguridad se concede a una entidad despus de comprobar una serie de referencias, para asegurar la identidad del receptor de los datos cifrados. Se construye a partir de la clave pblica del servidor solicitante, junto con algunos datos bsicos del mismo y es firmado por la autoridad de certificacin correspondiente con su clave privada. Para informarse ms sobre certificados y autoridades de certificacin, se pueden ver las pginas de Verisign o de OpenSSL. En la prctica, sabremos que el servidor es seguro porque en nuestro navegador veremos un candado cerrado en la parte izquierda de la barra de direcciones. Advertencia: Una llave entera o un candado cerrado no garantizan una comunicacin segura. Es necesario comprobar el certificado. Otro cambio importante es el identificador de protocolo en la URL: ya no empieza con http, sino con https.

Obtener un certificado usando OpenSSL (Apache)

Tomemos por ejemplo a una empresa: "Pato, S.A.". Para crear nuestros certificados usaremos la aplicacin Openssl. Ejecutamos
root@laptop:/# openssl version OpenSSL 0.9.8o 01 Jun 2010 root@laptop:/#

En caso de no estar instalado, ejecutamos (sistemas basados en Debian)

root@laptop:/# sudo aptitude install openssl root@laptop:/#

Instalacin inicial Todo el trabajo lo haremos dentro de un directorio de trabajo. Para fines prcticos usaremos CA; dentro de este directorio a la vez hay que crear otros dos, llamados certificados y privado. El primero es donde se guardar una copia de cada certificado que firmemos y en el otro directorio se guardar la llave privada.
#> mkdir CA

#> cd CA #> mkdir certificados privado

Es muy importante no perder la llave privada que se genere, ya que con esta podremos firmar o renovar certificados, y mucho menos drsela a nadie, ya que toda nuestra seguridad radica en la confidencialidad de la llave privada que se guardar en el directorio privado. Lo siguiente ser crear un par de archivos que en conjunto formarn la base de datos de los certificados autofirmados.
#> echo '01' > serial #> > index.txt (o tambin de la siguiente manera) #> touch index.txt

El primer archivo 'serial' simplemente contiene el siguiente nmero de serie de nuestros certificados, ya que apenas vamos a crear el primero su nmero de serie ser 01, despus de crearlo se actualizar a 02 y asi sucesivamente. 'index.txt' ser la base de datos propiamente en base al nmero de serie. Archivo de configuracin (anexo 1) Creamos el archivo openssl.cnf y lo guardaremos dentro de nuestro directorio CA (Ver Anexo 1, al final del documento). El archivo se divide en secciones indicadas entre [ corchetes ], y cada seccin tiene sus propias variables. La idea principal del archivo de configuracin es de simplificar el uso de los subcomados del comando openssl, que tiene tres subopciones principales: ca, req y x509. Hay una directiva o variable importante que es distinguished_name (DN) o nombre distinguido en espaol, esta a su vez hace referencia a una seccin que tiene los datos bsicos de la autoridad certificadora (CA) y que tambin servirn estos datos para cuando se generen certificados. Mas simple: el DN son los campos que identifican al propietario del certificado. A esta altura el directorio CA contiene
#> ls -l drwxr-xr-x 2 root root 4096 ene 26 13:23 certificados -rw-r--r-- 1 root root 0 ene 26 13:24 index.txt -rwxr--r-- 1 root root 4776 ene 26 2006 openssl.cnf drwxr-xr-x 2 root root 4096 ene 26 13:23 privado -rw-r--r-- 1 root root 3 ene 26 13:23 serial #>

Creando el certificado raz El certificado es el que nos convertir en una autoridad certificadora CA, asi que cuando emitamos el comando lo primero que nos pedira es el "pass phrase" o mas llanamente, una contrasea pero en forma de una frase. Esta contrasea es de vital importancia ya que es con la que validaremos nuestra autoridad para despus poder crear certificados autofirmados que son los que realmente usaremos en nuestro sitio. Debe ser preferentemente muy compleja, con maysculas, minsculas, espacios, nmeros y por supuesto smbolos, un buen ejemplo sera:

'el Der3ch0 al #respE5to( -a+jeo_Ez-la=pAz8%. =)'

Tenemos todo listo incluyendo una buena contrasea.

#> openssl req -new -x509 -extensions v3_ca -keyout privado/cakey.pem \ -out cacert.pem -days 3650 -config ./openssl.cnf Generating a 1024 bit RSA private key ....++++++ .......++++++ writing new private key to 'privado/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. ----Nombre de la organizacion [Pato, S.A.]: Departamento o division []:Sistemas Correo electronico []:info@pato.com Ciudad o distrito [Leon]: Estado o provincia [Guanajuato]: Codigo del pais (dos letras) [MX]: Nombre comun (hostname o IP) []:www.pato.com

Antes de analizar la salida, veamos las opciones indicadas: * * * * * * req -new -x509 ---> crear un certificado nuevo autofirmado -extensions v3_ca ---> crear un certificado raz CA -keyout ---> nombre y donde guardar la llave privada -out ---> nombre del certificado raz CA -days 3650 ---> el certificado ser vlido por 3650 das (10 aos) -config ---> archivo de configuracin a utilizar

Con respecto al resultado producido, lo primero que se indico fue escribir y verificar la contrasea, despus vienen los datos para identificar al propietario del certificado CA, que como se puede apreciar los prompts y los datos por default provienen del archivo de configuracin. Si no se especifica la opcin -days entonces el certificado ser vlido por solo 30 das. (En el archivo de configuracin es posible inicar la variable default_days = valor, en la seccin de CA_default) Lo anterior da por resultado dos archivos: * Un certificado raz CA (cacert.pem) * Una llave privada (privado/cakey.pem) (La extensin "pem" es de Privacy Enhanced Message) El archivo cacert.pem es el que se podra mandar a nuestros clientes o usuarios del sistema, y que estos lo instalen en su navegador, de esta manera quedaramos como un CA ms vlido para el navegador y cada vez que el cliente se conecte a nuestro

servidor, su navegador ya no estara mostrando el dilogo donde se pide aceptar la conexin segura. Veamos como lucen estos archivos:
#> more cacert.pem -----BEGIN CERTIFICATE----MIIDkzCCAvygAwIBAgIJAKTOKYwDdhLRMA0GCSqGSIb3DQEBBAUAMIGOMRMwEQYD VQQKEwpQYXRvLCBTLkEuMREwDwYDVQQLEwhTaXN0ZW1hczEcMBoGCSqGSIb3DQEJ ARYNaW5mb0BwYXRvLmNvbTENMAsGA1UEBxMETGVvbjETMBEGA1UECBMKR3VhbmFq dWF0bzELMAkGA1UEBhMCTVgxFTATBgNVBAMTDHd3dy5wYXRvLmNvbTAeFw0wNjAx MjcwMTU4NDFaFw0wNjAyMjYwMTU4NDFaMIGOMRMwEQYDVQQKEwpQYXRvLCBTLkEu MREwDwYDVQQLEwhTaXN0ZW1hczEcMBoGCSqGSIb3DQEJARYNaW5mb0BwYXRvLmNv bTENMAsGA1UEBxMETGVvbjETMBEGA1UECBMKR3VhbmFqdWF0bzELMAkGA1UEBhMC TVgxFTATBgNVBAMTDHd3dy5wYXRvLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA52zeMbFW2lSRfcZl6yrqXDAzbwL4ZoXCGRnbo6Wr8S1yp/KYW9/TMHlX nFrKXzM+RP7St/LzlkW1Zt8L+bCZ3XMBLGaa7qHgOagZxhcq1XTLL3CcvaCuzzKT 8izENDnGr4abtvkAJW4QqRCP7iVvVf8Db624JclbhBYMBUqPEJsCAwEAAaOB9jCB 8zAMBgNVHRMEBTADAQH/MB0GA1UdDgQWBBS6tkzuiG3DR+AO1Oy32QjZvBbpLTCB wwYDVR0jBIG7MIG4gBS6tkzuiG3DR+AO1Oy32QjZvBbpLaGBlKSBkTCBjjETMBEG A1UEChMKUGF0bywgUy5BLjERMA8GA1UECxMIU2lzdGVtYXMxHDAaBgkqhkiG9w0B CQEWDWluZm9AcGF0by5jb20xDTALBgNVBAcTBExlb24xEzARBgNVBAgTCkd1YW5h anVhdG8xCzAJBgNVBAYTAk1YMRUwEwYDVQQDEwx3d3cucGF0by5jb22CCQCkzimM A3YS0TANBgkqhkiG9w0BAQQFAAOBgQAEdK/hgtIqEVw551fs3G3+TKoH9b9t3TJa aelLJtKSQAoKzsnhwl88Hm78LEXK/kYufX6M6rDQHDpmcBV3DhIkEEHrBPJ4KBuV +aC559Xqb828YCkNVWDIIefFuxfaWBfd4HHPNKBBiyE5rp2IXN8AgUy7mVkMbsto RCAZS/IhAg== -----END CERTIFICATE----#>

Y la llave privada tiene el siguiente contenido:

#> more privado/cakey.pem -----BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,0FC86D0DBD03A241 TQIqQQKIB2ZFaZUqTwk+k658Lj+RStlsdLKkAeWN+B7ibgtLPN8OHNZM2cOts9Se qRSVfWSSXzhFsh2fbDoBNx+JYKgPh7+IeBhQ1PJNrPAbyrC1GEybtn+WPEWzBNdo 2e4kOeIzgm7LxeAoofmKgvqcDLRlY34TCFHgnSAQIuZC3iZ8YZAFcMWo3owoUpP7 TKL8W1PtFTVviMC5I7A0rN9en9EQY4QazXDIIVc60uIcKONyEF4fj3aE87+m2lD5 fqfMWG7Ce8GBBOUPL1YtLSC9LOBNhulFqceMvfysLFxToPUP4rs+n+upxnGsHnmF YjsPR3lqAt41JehsO+sUSqoX6I83Q/706g/87XV0JPMDCXBejRI/vW5KgJ0Ux2gv yQfYvHGs5RZl8NfK9AUEcC053VSkjwmuT/anu7czyJC+IG2XTHqoLu6g6CjLNe3b bm/FhymOKENGnKSvA6Mny+NThhSOImhibB0fvsW5Fygi7SboZpXZFJBfEqHzUGvW guzfVF4G7Rhs29Bue0dJOMT2ptFPrjUn0582O7WVIE7aV7msygmt2QUYIWykEt7s O5hzdhguw2WZu0/gl2y5Mpjo3W5SrrCOoxC2mcPutoNhV+DFCQxcbCLsu5PnLBoF HFBCe6ynh/6bIpakGJorzdsB9QqhGdgvbRQbrpYfAl+QHr6/8kyEu4OG+PmoD2ZR O/gAGlSIlDowesmWXGk6l7vZc5BxU1qQVI5QLVr3X7ilavi6+EVSWDF8dFVetYBP dPYYAEzVJVEiDH8yxQ4NoGk+9gmxKVfmejnmtbSHuR20cXbHOKJGmQ== -----END RSA PRIVATE KEY-----

Podemos tambin consultar informacin especfica del certificado raz, fechas, a quien pertenece etc.
#> openssl x509 -in cacert.pem -noout -dates notBefore=Jan 27 02:22:33 2006 GMT notAfter=Jan 25 02:22:33 2016 GMT

En el ejemplo anterior se aprecia que el certificado si fue generado con una validez de 10 aos, tal como se indic. Otros ejemplos de consulta pero se omite la salida:

#> openssl x509 -in cacert.pem -noout -text #> openssl x509 -in cacert.pem -noout -purpose

Creando un Certificate Signing Request(CSR) (Solicitud de firmado de certificado) En este punto, ya tenemos un certificado raz que nos vlida como CA, aunque sin mas autoridad que nuestro propio dominio. Podemos crear certificados no solo para https, sino tambin spop, o simap o crear autentificacin para vpn's a travs de apliaciones como stunnel. Los siguientes procedimientos son los que a continuacin hay que realizar: * Crear una llave privada y una solicitud de certificado. * Firmar la solicitud para generar un certificado autofirmado. Volveremos entonces a usar el comando openssl para lograr lo anterior. Casi todo ser igual a lo anterior. Slo que en la solictud de firmado no es necesario especificar una contrasea, aunque si se generar una clave privada para la solictud. Veamos.
#> openssl req -new -nodes -out pato-cert.pem -config ./openssl.cnf Generating a 1024 bit RSA private key ......................................................++++++ .......++++++ writing new private key to 'key.pem' ----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. ----Nombre de la organizacion [Pato, S.A.]: Departamento o division []:Sistemas Correo electronico []:info@pato.com Ciudad o distrito [Leon]: Estado o provincia [Guanajuato]: Codigo del pais (dos letras) [MX]: Nombre comun (hostname o IP) []:www.pato.com

Lo ltimo que nos pregunto en la parte DN (distinguished name) es el nombre comn (CN common name), aqui es sumamente importante indicarlo igual a como esta el certificado raz generado previamente, como se trata de un servidor web, lo correcto es poner su FQDN que es www.pato.com, no debe indicarse ni pato.com ni http://www.pato.com Lo anterior genera dos archivos: * pato-cert.pem ---> el certificate signing request (csr) * key.pem ---> la llave privada En cuanto a las opciones, se uso req de request solicitando un certificado nuevo, -out que es el nombre del certificado que deseamos firmar, -config de nuevo toma el archivo de configuracin que creamos. La opcin -nodes se especifica para indicar que no deseamos contrasea en la llave privada.

Observemos el contenido de la solictud:

#> more pato-cert.pem -----BEGIN CERTIFICATE REQUEST----MIIBwTCCASoCAQAwRjETMBEGA1UEChMKUGF0bywgUy5BLjENMAsGA1UEBxMETGVv bjETMBEGA1UECBMKR3VhbmFqdWF0bzELMAkGA1UEBhMCTVgwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMMvo7xg3vmdlf/38yA68uzNq2WYTtkyecuBnUgocOqD gc0Yl2hrfXN6lHl65kxeRFVdEBYhGgA7JoISivuDTvWwVOIxmH5HOFzZlIPIZ3xT hHCdWUKipXhcsVCTGV+rbB1F9kkIAMrmtaNH2+Zj261jdB7eX960l1EqQaWt71dJ AgMBAAGgOzA5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYEFGVf A/CDDXl6LQs1MH/XItqJl/8kMA0GCSqGSIb3DQEBBAUAA4GBAJH0sO7bR+dJL67p xK5oEG9LPA2KcP+W7Vn5edpaLtUs/jYyvhQaCdSBxbMkV42nmt9DGD5p5caTFk3M 5guV9f087K+eYnUGILGQS51tXFcmYramZLETzs7nVfwGnXGsDGyKDkG6VTkx46pz JrRTJfWBpWpo4FWg/Fi2l4E4PLv8 -----END CERTIFICATE REQUEST-----

Se trata de una solicitud de certificacin (Certificate Request), es decir todava tiene que ser firmado por una autoridad certificadora CA que somos nosotros mismos. Antes de hacer este ltimo paso podemos observar el contenido de nuestra solictud en un formato mas legible e incluso verificar que estn los datos correctos. (Se omite la salida)
#> openssl req -in pato-cert.pem -text -verify -noout

Firmando el certificado Por ltimo firmaremos la solicitud que hicimos en el paso previo. Para firmarlo necesitaremos indicar la contrasea que autentifique que somos la CA y que que por serlo tenemos la autoridad de autorizar (firmar) certificados. (Para nuestro propio uso).
#> openssl ca -out certificado-pato.pem -config ./openssl.cnf -days 3650 \ -infiles pato-cert.pem Using configuration from ./openssl.cnf Enter pass phrase for ./privado/cakey.pem: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows organizationName :PRINTABLE:'Pato, S.A.' organizationalUnitName:PRINTABLE:'Sistemas' localityName :PRINTABLE:'Leon' stateOrProvinceName :PRINTABLE:'Guanajuato' countryName :PRINTABLE:'MX' commonName :PRINTABLE:'www.pato.com' Certificate is to be certified until Jan 26 00:10:10 2016 GMT (3650 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 #>

Usamos la opcin ca que indica que firmaremos un certificado como autoridad certificadora (CA) que somos, la salida -out ser el archivo certificado-pato.pem usando las opciones -config del archivo de configuracin y la solicitud de firmado se

especific con la opcin -infiles que tom los datos del archivo pato-cert.pem creado en el paso previo. Aqui se nos pidi la contrasea, que es la que se indic cuando creamos cacert.pem que corresponde a nuestro certificado raz que nos identifica como CA. El certificado ser vlido por 10 aos -days y despus se nos pregunt que si queriamos firmarlo, por supuesto que si, y la ltima pregunta es por si queremos guardar este certificado ya autofirmado en la base de datos, a lo que tambin contestamos que si.
#> more serial 02

Se comprueba que ya aumento el nmero de serie a 02, es decir, el siguiente certificado que firmemos ser ese nmero.
#> more index.txt V 160126001010Z 01 unknown /C=MX/ST=Guanajuato/O=Pato, S.A./OU=Sistemas/CN=www.pato.com

En el archivo index.txt el tercer campo indica 01, que es el nmero de serie para el certificado recien creado y muestra tambin los campos del DN.
#> ls -l certificados total 4 -rw-r--r-- 1 root root 2597 ene 27 18:10 01.pem

En el directorio de certificados se guarda tambin con el correspondiente nmero de serie (01.pem) un archivo que complementa la base de datos de certificados que podemos ir creando. Y por ltimo tenemos el certificado en si:
#> ls -l certificado-pato.pem -rw-r--r-- 1 root root 2597 ene 27 18:10 certificado-pato.pem

Y podemos inspeccionarlo:
#> openssl x509 -in certificado-pato.pem -noout -text -purpose

Instalando el certificado y la llave para Apache Tenemos entonces dos elementos ya generados que necesitaremos para Apache: * key.pem ---> La llave privada * certificado-pato.pem ---> Certificado autofirmado Hay algunas aplicaciones (no Apache) que requieren estos dos elementos en un solo archivo, como en el caso de stunnel:
# > cat key.pem certificado-pato.pem > key-cert-pato.pem

Simplemente se concatenan los dos archivos en uno. Pero esto no es necesario para el caso del servidor Web Apache. Lo que hay que hacer es copiar nuestros dos archivos

en un directorio, de hecho podran quedarse donde estn, es lo de menos, pero por cuestin de orden y organizacin vamos a copiarlos a /etc/httpd/conf que en la mayora de distribucciones es el directorio de configuracin del Apache. NOTA IMPORTANTE: por ningn motivo copiar dentro del directorio raz del servicio de Apache, como /var/www/html ya que podras dejar expuestos los archivos a todo el mundo y ser vulnerados.
#> cp key.pem certificado-pato.pem /etc/httpd/conf/

Una vez copiados los archivos, hay que crear un servidor virtual en Apache, esto dentro del archivo de configuracin httpd.conf, en algunas distribuciones como Fedora y otras dentro de /etc/httpd/conf.d hay un archivo llamado ssl.conf que es donde viene un servidor virtual ya creado, se puede tomar como plantilla.
<VirtualHost 192.168.100.1:443> ServerName www.pato.com DocumentRoot /var/www/consulta ... (dems directivas del sitio) SSLEngine on SSLCertificateFile /etc/httpd/conf/certificado-pato.pem SSLCertificateKeyFile /etc/httpd/conf/key.pem </VirtualHost>

Tambin debe existir una lnea que abre el puerto 443 a la escucha de paquetes. Esta fuera de las directivas del servidor virtual. Si no est se debe agregar:
Listen 443

Forzosamente debe ser un servidor virtual basado en IP, aqui lo indique con una IP (192.168.100.1) de una red privada pero en tu caso indica la IP homologada o real de tu sitio web o deja tu IP privada si es una Intranet. La directiva DocumentRoot apunta a /var/www/consulta y no a /var/www/html, esto es para que en /var/www/html quede un simple index.html con una lnea como la siguiente:
<meta http-equiv="refresh" content="0;url=https://www.pato.com">

Esto har que el usuario en su navegador especifique http://www.pato.com, dirigido al puerto 80 y es cachado por la pgina index.html con el cdigo que redirige al mismo servidor pero a https, es decir, puerto 443 y es donde entra en funcin el servidor virtual que a la vez redirige a /var/www/consulta donde se inicia la aplicacin de consulta o lo que se tenga. Pero lo interesante es que no hay necesidad de indicarle al usuario que indique https en el url. Al usuario le aparecer un dilogo pidindole que acepte el certificado de la empresa Pato, S.A. Distribuir el certificado raz CA Para evitar que a los clientes cada vez que ingresen al sitio les salga el molesto dilogo que pide aceptar el certificado, la solucin es distribur el archivo cacert.pem. Este archivo es el que identifica como una autoridad certificadora. Se puede poner a

descarga desde el propio sitio, o mandarlo por correo, por ejemplo. Cuando el cliente lo tenga en su equipo deber importarlo al browser o navegador. Todos los navegadores en sus preferencias o herramientas tienen una opcin de certificados y desde ah existe un botn importar para realizar esto. protocolo SSL 2.0 Si todo funcion bien, tienes ahora un sitio con encriptacin de extremo a extremo y todo el trfico viaja seguro. Referencias Buena parte de esta gua proviene de los siguientes sitios:
* * * * * http://www.linuxtotal.com.mx/index.php?cont=info_seyre_001 http://www.eclectica.ca/howto/ssl-cert-howto.php http://www.technoids.org/openssl.cnf.html http://www.squarebox.co.uk/cgi-squarebox/manServer/usr/share/man/man1/ca.1ssl http://www.openssl.org

Y tambin de las mismas pginas del manual:

#> #> #> #> man man man man openssl req ca x509

1.3 Limitaciones del protocolo.

El Protocolo SSL a pesar de ofrecer seguridad, a veces presenta limitaciones, entre ellas bugs (fallos) u otro tipo de vulnerabilidades, que por lo general son publicados por la gran comunidad de desarrolladores del proyecto OpenSSL. Algunas de estas limitaciones son: - Uso de versiones desactualizadas de OpenSSL. Se sabe que el protocolo SSL 2.0 tiene grandes debilidades criptogrficas y solo se admite como reserva. - "Hombre en el medio" (o 'man in the middle' en ingls). Es un atacante que obliga a un cliente y a un servidor a pasar las negociaciones mediante l, sin ser descubierto. - Hbitos de usuarios. El usuario promedio de internet no presta mucha atencin a los cambios de protocolos (entre http y https por ejemplo) y a veces no le da importancia a si una pgina de identificacin es segura o no.

2. Exploracin de Vulnerabilidades (herramientas). 2.1 SSLStrip.

Requisitos: SSL Strip > http://www.thoughtcrime.org/software/sslstrip/ Ettercap > http://www.ettercap.sourceforge.net/ ARPspoof > aptitude install dsniff Una vez instalado, iniciamos Ettercap en modo GUI y ejecutamos en el men: Snifff > Unified Sniffing > Seleccionar el dispositivo (wlan0, eth0...) > Scan hosts > Host List A continuacin se pueden ver los clientes disponibles. Seleccionamos el de preferencia y comenzamos con Start. A continuacin configuramos las Iptables usando
echo "1" > /proc/sys/net/ipv4/ip_forward iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

Luego hacemos un ARP spoofing ejecutando

arpspoof -i <interface (ej: wlan0)> -t <IP_vctima> <IP_router>

Abrimos un terminal en la carpeta donde descomprimimos SSL Strip y ejecutamos usando python
./sslstrip.py -a -l 8080

En otra terminal podemos ver el log usando cat (tambin con nano, kate o similares). Es recomendable filtrar la lectura usando con grep etiquetas como Passwd, email, www... Por ejemplo:
cd /sslstrip-0.7 cat sslstrip.log | grep [etiqueta]

Cmo funciona? En primer lugar, ARPSpoof convence a un host que nuestra direccin MAC es la direccin MAC del router, y el objetivo empieza a enviar todo el trfico de red. El kernel enva todo excepto el trfico destinado al puerto 80, que vuelve a dirigir a $ListenPort (8080, por ejemplo). En este punto SSL Strip recibe todo el trfico y genera el log.

2.2 Ettercap (LAN Sniffer).

Ettercap es una herramienta de monitoreo del trfico web. Para configurarla especficamente para capturar paquetes del protocolo que nos interesa, debemos modificar su archivo de configuracin (/etc/etter.conf) de la siguiente manera descomentando la siguiente lnea:
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

A continuacin iniciamos Ettercap en modo GUI y capturamos, de la siguiente manera:

ettercap -C Sniff -> Unified Sniffing Hosts -> Scan for hosts Start -> Start Sniffing Mitm -> Arp poisoning View -> Connections I (nombre_fichero) -> Para generar log de resultados

Podemos hacer una bsqueda con grep en el archivo del log. Capturas:

2.3 FireSheep (Extensin de Firefox).

Firesheep es una extensin para Firefox (Windows, Mac OS X) que nos pone extremadamente fcil algo que ya era posible antes, pero que seguramente no hayas intentado. Se trata de capturar paquetes en una red pblica para robar sesiones de terceros. Al instalarla, se pondr en una la barra lateral a escuchar datos interesantes que le lleguen, y cuando encuentre uno con datos de una sesin nos mostrar su nombre y foto. A partir de ah solo se necesita un doble click para robarnos nuestra cuenta de Google, Facebook, Twitter, Flickr o Windows Live. Este proceso totalmente automatizado es la mejor manera de concienciarnos para solicitar a los servicios importantes que usen siempre conexiones cifradas. Si antes estaba al alcance de alguien con mnimos conocimientos tcnicos sobre el tema, ahora cualquiera puede hacerlo. Eric Butler, un desarrollador de aplicaciones y software ha hecho un plugin para Firefox que brinda a cualquiera la posibilidad de hackear una cuenta Facebook, o cualquier otra cosa, con un proceso automatizado llamado Firesheep, y que present el ToorCon (una conferencia Hacker en San Diego, Estados Unidos) para demostrar lo frgil que es nuestra seguridad en la Red. Para funcionar, esta extensin necesita que ests conectado a una red (mejor si es Wifi pblica y abierta), como las que se disfrutan en algunos aeropuertos, cafeteras, hospitales, universidades y otros edificios pblicos. Esta extensin incluye soporte para casi 30 sitios sociales e incluso permite escribir plugins para aadir los sitios que queramos. Una vez instalado, nos aseguramos que FireSheep est rastreando la red correcta yendo a preferencias > Capture y elegimos la red apropiada. Luego, click en Start Capturing y ser paciente para ver como la extencin captura nuestros datos.

Sitio de descarga: FireSheep http://github.com/codebutler/firesheep/downloads Requisitos en Windows: WinPcap http://www.winpcap.org/install/default.htm

3. Contramedidas: cmo detectar y evitar ataques MiTM

En un entorno de produccin (empresa, oficina, fbrica, etc.) es importante en primer lugar generar hbitos de uso seguro, facilitando software de navegacin con complementos adecuados. Muchas veces se pasa por alto que los responsables de los distintos sectores usan las mismas contraseas para servicios web (mail, redes sociales, foros, etc.) que las que utilizan en su acceso a los servidores de la empresa. Por lo tanto se debe fomentar hbitos seguros en el acceso a internet, comenzando por el navegador elegido. Tambin es importante la monitorizacin y deteccin de ataques en reas crticas, antes de que puedan generalizarse. Tanto para equipos destinados a servidores como los de uso de clientes de escritorio. Para ello proponemos dos medidas: la correcta configuracin de navegadores y la monitorizacin de terminales usando herramientas de inspeccin de redes.

3.1 Navegacin segura.

Existen complementos del navegador que restringen el acceso de sitios conocidos limitndolos slo al puerto seguro, modificando o reescribiendo las solicitudes usando el protocolo HTTPS. Con esto se busca solucionar el problema de muchos sitios que ofrecen un soporte limitado de encriptacin, o que presentan una mezcla de contenido cifrado y sin cifrar que vuelven su acceso inseguro. Por el momento hay tres navegadores que ofrecen este tipo de complementos. El primero es Firefox, a travs del add-on HTTPS everywhere. Se trata de una colaboracin con los responsables del proyecto Tor (servicios de navegacin annima sobre TCP). Se instala como cualquier extensin del navegador, ingresando a la pgina https://www.eff.org/https-everywhere. Cabe destacar que es el nico que ofrece la posibilidad de reescribir las solicitudes en HTTPS cuando el sitio no ofrece una encriptacin nativa. Otro navegador es Google Chrome (Chromium), que ofrece complementos como KB SSL enforcer (https://code.google.com/p/kbsslenforcer/). Su funcin es redirigir los sitios a su versin ssl (TLS) si estn disponibles. El principal problema es que, por una limitacin del navegador, KB SSL enforcer redirige mientras la pgina se est cargando. Eso puede permitir la transmisin (y captura) de paquetes no cifrados, incluyendo cookies de sesin autenticada.

Estos dos complementos estn disponibles con una licencia GPL y en desarrollo activo. Por ltimo, cabe mencionar el complemento Redirect to HTTPS de Opera https://addons.opera.com/addons/extensions/details/redirect-to-https/1.96/ . Tiene la misma funcionalidad (y la misma limitacin) que la extensin de Chrome.

3.2 Detectar Ataques MitM con Ettercap.

Quiz los ataques ms comunes y peligrosos en las redes locales sean los conocidos como ataques de "Hombre en medio" - Man in The Middle (MitM) -. En ellos el objetivo del atacante es conseguir que las comunicaciones que genera la vctima, ya sean con su puerta de enlace a Internet o con cualquier servidor interno, pasen por el equipo del atacante con el fin de simplemente capturar informacin sensible no cifrada o manipularle y engaarle con ataques ms elaborados. Una vez que la vctima tiene controlado su canal de comunicaciones no podra fiarse de ninguna informacin que recibiera, ya que podran, por ejemplo, manipularle las respuestas de los servidores DNS y hacer que navegara hacia sitios falsos, por citar alguna de los muchos ataques que se podran realizar a posteriori. La forma ms comn de hacer un ataque de MitM es mediante el envenenamiento de la cach ARP de la vctima con informacin falsa. Para ello, el atacante hace que, en la tabla de direcciones MAC asociadas a direcciones IP que guarda cada sistema operativo, la vctima piense que la direccin MAC de su puerta de enlace - o cualquier otro servidor interno que el atacante desee suplantar - sea la del equipo que realiza el ataque MitM. As, cualquier mensaje enviado a la direccin IP de Internet que debiera pasar por la puerta de enlace, ser enviado sin saberlo al atacante que capturar la informacin y/o la manipular para reenviarla despus a sus destino. Detectar ataques MitM mediante inspeccin de la red Existen muchas soluciones para detectar los ataques MitM, una de ellas es detectarlo mediante el anlisis de los paquetes ARP que circular por la red. sta tarea puede parecer muy tediosa, pero existen diversas aplicaciones que nos simplifican el trabajo. De hecho, este mtodo que vamos a ver es utilizado por Sistemas de Deteccin de Intrusiones (IDS) profesionales que suelen implantarse en redes corporativas. Para este ejemplo vamos a utilizar la aplicacin Ettercap en Linux ms un plugin llamado arp_cop que realiza un anlisis de los paquetes ARP mostrando posible actividad sospechosa desde mquinas que estn realizando este tipo de ataques. Para llevar a cabo la instalacin de Ettercap ms sus mdulos podemos realizarlo mediante el comando aptitude install ettercap. Se instalar Ettercap con una lista de plugins tiles para anlisis y ataques de red. Esta lista se puede ver con el comando ettercap -P list.

Posteriormente, hemos realizado un pequeo script para mejorar la eficacia del plugin arp_cop, forzando a realizar previamente un escaneo ARP de los equipos de la red para generar un estado inicial. De este modo, nada ms arrancar el plugin ya se dispondr de una lista completa de los equipos de la red con la asociacin de direccin IP y direccin MAC de cada uno de ellos. Uno de los requisitos para realizar el escaneo ARP es tener instalada la aplicacin nmap y disponer de permisos de root. nmap tambin puede ser instalada a travs de aptitude install nmap. Para una mejor usabilidad es aconsejable copiar este script en /bin/arpscan y proporcionarle permisos de ejecucin mediante el comando chmod o+rx /bin/arpscan.
#!/bin/bash (sudo nmap -sP 192.168.0.0-255 > /dev/null &) & /opt/local/bin/ettercap -T -q -d -i en0 -P arp_cop

La generacin de este escaneo previo permitir conocer cul es la asignacin de direcciones MAC y direcciones IP en un estado inicial en la que nuestro equipo, recin conectado a la red, no est atacado para as poder comparar con l viendo las modificaciones que se suceden en la asignacin de direcciones. Evidentemente, si la red est atacada en ese momento no se podr tener la garanta absoluta de que funcione la deteccin y es por ello que, lo ideal, sera que hubiera una construccin manual de esta tabla y/o una verificacin de los valores obtenidos. Una vez est todo instalado, podemos monitorizar los ataques o actividades extraas que se realicen en el protocolo ARP de la red a la que estamos conectados, tal y como se ve en la siguiente captura. En ella se puede ver como arp_cop detecta en tiempo real cuando nuevos equipos entran en la red, mostrando su direccin IP y su direccin MAC asociada, y cuando alguien trata de suplantar la direccin IP de otro equipo,

como en el ejemplo que se ve, donde el equipo con la direccin IP 192.168.1.68 trata de realizar un ataque MitM hacindose pasar por la direccin 192.168.1.1.

Otras medidas de respuesta contra ataques MitM Como usuario de una red nueva, con este pequeo script se puede realizar la deteccin de actividad sospechosa, que te puede ayudar a conocer el nivel de riesgo que tienes en la red en la que te estas conectando. Sin embargo, si eres un usuario vengativo, tras detectar un ataque de este tipo, existen herramientas de respuesta al ataque que pueden ser realizadas a travs de los plugins de Ettercap. Entre los plugins disponibles se puede hacer uso de dos_attack, tal y como se ve a continuacin, que realiza un intento de ataque de Denegacin de Servicio contra la direccin IP que trataba de realizarnos un ataque de MiTM. Ettercap iniciado en interfaz de usuario grfico (ettercap -C)

En realizad un usuario no debera encargarse de las medidas de monitorizacin y deteccin de ataques en la red, sino que debera ser responsabilidad de los equipos de seguridad y red, pero debido a la proliferacin de las redes y a la necesidad de transmitir datos confidenciales en redes de terceros por motivos de movilidad, hace que no venga de ms tener claro que sucede en la red a la que te ests conectando. Por ltimo, queremos recordar que el uso de nmap puede ser detectado en algunas redes como un ataque, as que, si la red tiene un IDS, no deberas ejecutarlo en script y, simplemente, tener arp_cop lanzado. Su eficacia ser menor, pero no levantars las alertas en todos los sistemas de proteccin de la red (si los tienen).

Referencia: http://www.seguridadapple.com/2011/03/detectar-ataques-man-in-middlecon.html

ANEXOS 1. openssl.cnf
# # # # # # # ************************************************************************************* www.linuxtotal.com.mx sergio.gonzalez.duran@gmail.com Archivo de configuracion para openssl ***** openssl.cnf ****** =. # variable que establece el directorio de trabajo

dir

# seccion que permite convertirnos en una CA # solo se hace referncia a otra seccin CA_default [ ca ] default_ca = CA_default [ CA_default ] serial = $dir/serial # archivo que guarda el siguiente nmero de serie database = $dir/index.txt # archvio que guarda la bd de certificados new_certs_dir = $dir/certificados # dir que guarda los certificados generados certificate = $dir/cacert.pem # nombre del archivo del certificado raz private_key = $dir/privado/cakey.pem # llave privada del certificado raz default_md = md5 # algoritmo de dispersin usado preserve = no # Indica si se preserva o no el orden de los # campos del DN cuando se pasa a los certs. nameopt = default_ca # esta opcion y la siguiente permiten mostrar # detalles del certificado certopt = default_ca policy = policy_match # indica el nombre de la seccion # donde se especifica que campos son # obligatorios, opcionales y cuales deben ser # iguales al certificado raz # seccion de politicas para la emision de certificados [ policy_match ] countryName = match # match, obligatorio stateOrProvinceName = match organizationName = match organizationalUnitName = optional # optional, campo opcional commonName = supplied # supplied, debe estar en la peticin emailAddress = optional # seccion que indica como los certificados deben ser creados [ req ] default_bits = 1024 # tamao de la llave, si no se indica 512 default_keyfile = key.pem # nombre de la llave privada default_md = md5 # algoritmo de dispersin a utilizar string_mask = nombstr # caracteres permitidos en la mascara de la llave distinguished_name = req_distinguished_name # seccion para el nombre distinguido (DN) req_extensions = v3_req # seccion con mas extensiones que se aaden a la # peticion del certificado # seccion del nombre distinguido, el valor es el prompt que se vera en pantalla. # datos del propietario del certificado. # esta seccion define el contenido de datos de id que el certificado llevara. [ req_distinguished_name ] 0.organizationName = Nombre de la organizacion 0.organizationName_default = Pato, S.A. organizationalUnitName = Departamento o division

emailAddress = Correo electronico emailAddress_max = 40 localityName = Ciudad o distrito localityName_default = Leon stateOrProvinceName = Estado o provincia stateOrProvinceName_default = Guanajuato countryName = Codigo del pais (dos letras) countryName_default = MX countryName_min =2 countryName_max =2 commonName = Nombre comun (hostname o IP) commonName_max = 64 # si en la linea de comandos se indica la opcion -x509, # las siguientes extensiones tambien aplican [ v3_ca ] # indica que se trata de un certificado CA raz con autoridad para # firmar o revocar otros certificados basicConstraints = CA:TRUE # especifica bajo que metodo identificar a la llave publica que sera certificada subjectKeyIdentifier = hash # especifica como identifcar la llave publica

authorityKeyIdentifier = keyid:always,issuer:always # extensiones de la opcion req [ v3_req ] basicConstraints = CA:FALSE # los certificados firmados no son CA subjectKeyIdentifier = hash # *************************************************************************************

Otro openssl.cnf
# # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. #

# This definition stops the following lines choking if HOME isn't # defined. HOME RANDFILE =. = $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info: #oid_file oid_section = $ENV::HOME/.oid = new_oids

# To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions =

# (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca' and 'req'. # Add a simple OID like this: # testoid1=1.2.3.4 # Or use config file substitution like this: # testoid2=${testoid1}.5.6

####################################################################

[ ca ] default_ca = CA_default # The default ca section

#################################################################### [ CA_default ]

dir certs crl_dir

= ../../CA

# Where everything is kept = $dir/certs = $dir/crl = $dir/index.txt # Where the issued certs are kept # Where the issued crl are kept # database index file. # Set to 'no' to allow creation of # several ctificates with same subject.

database

#unique_subject = no

new_certs_dir = $dir/newcerts

# default place for new certs.

certificate serial crlnumber

= $dir/cacert.pem = $dir/serial = $dir/crlnumber

# The CA certificate

# The current serial number # the current crl number

# must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL

private_key RANDFILE

= $dir/private/cakey.pem# The private key = $dir/private/.rand # private random number file

x509_extensions = usr_cert

# The extentions to add to the cert

# Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt cert_opt = ca_default = ca_default # Subject Name options # Certificate field options

# Extension copying option: use with caution. # copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # crlnumber must also be commented out to leave a V1 CRL. # crl_extensions = crl_ext

default_days

= 365

# how long to certify for # how long before next CRL # which md to use. # keep passed DN ordering

default_crl_days= 30 default_md preserve = sha1 = no

# A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match

# For the CA policy [ policy_match ] countryName stateOrProvinceName organizationName = match = match = match

organizationalUnitName = optional commonName emailAddress = supplied = optional

# For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName stateOrProvinceName localityName organizationName = optional = optional = optional = optional

organizationalUnitName = optional commonName emailAddress = supplied = optional

#################################################################### [ req ] default_bits default_md default_keyfile = 1024 = sha1 = privkey.pem = req_distinguished_name

distinguished_name attributes

= req_attributes

x509_extensions = v3_ca # The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for # input_password = secret # output_password = secret

# This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString. # utf8only: only UTF8Strings. # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK:XXXX a literal mask value. # WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings # so use this option with caution! # we use PrintableString+UTF8String mask so if pure ASCII texts are used # the resulting certificates are compatible with Netscape string_mask = MASK:0x2002

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]

countryName countryName_default countryName_min countryName_max

= Country Name (2 letter code) = GB =2 =2

stateOrProvinceName stateOrProvinceName_default

= State or Province Name (full name) = Berkshire

localityName localityName_default

= Locality Name (eg, city) = Newbury

0.organizationName

= Organization Name (eg, company) = My Company Ltd

0.organizationName_default

# we can do this but it is not needed normally :-) #1.organizationName #1.organizationName_default = Second Organization Name (eg, company) = World Wide Web Pty Ltd

organizationalUnitName

= Organizational Unit Name (eg, section)

#organizationalUnitName_default =

commonName commonName_max

= Common Name (eg, your name or your server\'s hostname) = 64

emailAddress emailAddress_max

= Email Address = 64

# SET-ex3

= SET extension number 3

[ req_attributes ] challengePassword challengePassword_min = A challenge password =4

challengePassword_max

= 20

unstructuredName

= An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing.

# This is OK for an SSL server. # nsCertType = server

# For an object signing certificate this would be used. # nsCertType = objsign

# For normal client use this is typical # nsCertType = client, email

# and for everything including object signing: # nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.

nsComment

= "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectAltName=email:move

# Copy subject details # issuerAltName=issuer:copy

#nsCaRevocationUrl #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName

= http://www.domain.dom/ca-crl.pem

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]

# Extensions for a typical CA

# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# This is what PKIX recommends but some broken software chokes on critical # extensions. #basicConstraints = critical,CA:true # So we do this instead. basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will # prevent it being used as an test self-signed certificate it is best # left out by default. # keyUsage = cRLSign, keyCertSign

# Some might want this also # nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation # subjectAltName=email:copy # Copy issuer details # issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only! # obj=DER:02:03 # Where 'obj' is a standard or added object

# You can even override a supported extension: # basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always,issuer:always

[ proxy_cert_ext ] # These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing.

# This is OK for an SSL server. # nsCertType = server

# For an object signing certificate this would be used. # nsCertType = objsign

# For normal client use this is typical # nsCertType = client, email

# and for everything including object signing:

# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always

# This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectAltName=email:move

# Copy subject details # issuerAltName=issuer:copy

#nsCaRevocationUrl #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName

= http://www.domain.dom/ca-crl.pem

# This really needs to be in place for it to be a proxy certificate. proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo