Repositorio con el código fuente de Unix los últimos 44 años

Diomidis Spinellis ha realizado un inmenso trabajo de recopilación del código fuente de Unix desde su concepción y primera versión en 1972 en Bell Labs hasta el actual FreeBSD 10.x. Las versión está ordenadas en el proyecto Unix History Repository en github. Toda una delicia para aquellos que quieran estudiar el origen Unix. El autor del mismo ha publicado un artículo titulado A Repository with 44 Years of Unix Evolution describiendo el proceso de creación del mismo. Tiene un gráfico muy chulo donde se puede ver la relación de las diferentes versiones.

En este repo no está incluido Linux - que es un clon de Unix - ni los sistemas Unix que derivaron de System V. Ah, ojalá Microsoft hiciese lo mismo con Windows, al menos sus versiones antiguas :)

tmutil: Controlar Time Machine desde la línea de comandos (I)

Introducción

Time Machine es una funcionalidad de copias de seguridad incluida en MacOS X desde la versión 10.5 (Leopard). Permite realizar las copias de seguridad tanto a discos duros locales o a sistemas compartidos en red compatibles con el software. Normalmente se controla desde la interfaz gráfica, pero existe una utilidad de línea de comandos que permite su control.

En el caso de Time Machine, la herramienta de línea de comandos que se encarga del control de las copias de seguridad es tmutil. Normalmente, este comando necesita ejecutarse con permisos de superusuario para realizar su función.

La estructura del comando es la siguiente

tmutil comando [parametros]

Manejo de los discos donde se van a realizar las copias de seguridad

El primer paso que hay que dar para poder utilizar Time Machine es configurar los volúmenes donde se van a realizar las copias de seguridad. Si tenemos un que está montado en /Volumes/My Passport y lo queremos usar para copiar de seguridad, se añade al sistema con el comando setdestination -a path donde en nuestro ejemplo path es /Volumes/My Passport. Con ayuda del comando destinationinfo se pueden ver los volúmenes que están añadidos. El comando destinationinfo permite el uso del argumento -X que vuelca la información en formato XML plist.

root#tmutil  setdestination  -a "/Volumes/My Passport"
root#tmutil  destinationinfo
> ==================================================
Name          : Backups
Kind          : Local
Mount Point   : /Volumes/Backups
ID            : C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83
====================================================
Name          : My Passport
Kind          : Local
Mount Point   : /Volumes/My Passport
ID            : 1044185E-607C-45A6-A5C2-E96BD7C0D836

De la información que vuelca destinationinfo hay dos puntos importantes:

• Cada volumen usado como copia de seguridad está identificado por un uuid único.
• Se utiliza > para señalar cual ha sido el volumen donde se ha intentado realizar la última copia de seguridad del sistema en el caso de que haya varios volúmenes disponibles. En el ejemplo anterior puede verse que que el disco con ID C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83 es el último donde se ha realizado dicha copia.

Para quitar un volumen que se está usando para copia de seguridad se utiliza el comando removedestination id, siendo id el identificador que se obtiene. Por ejemplo, para eliminar el volumen /Volumes/My Passport

root#tmutil removedestination  1044185E-607C-45A6-A5C2-E96BD7C0D836
root#tmutil destinationinfo
====================================================
Name          : Backups
Kind          : Local
Mount Point   : /Volumes/Backups
ID            : C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83

Realizar una copia de seguridad

Realizar la copia de seguridad es muy sencillo. Basta con utilizar el comando startbackup.

root#tmutil startbackup

Una vez lanzada la orden anterior, tmutil contactará con el servidor de copias de seguridad y comenzará la operación de copia. La orden anterior lanza la copia en segundo plano, retornando si no ha habido ningún error. Una cosa curiosa que ocurre al lanzar una copia así es que en caso de error, este aparece en la interfaz gráfica.

Esta orden admite una serie de parámetros

startbackup [-a | --auto] [-b | --block] [-r | --rotation] [-d | --destination dest_id]

• -a La copia de seguridad se realiza de manera similar a aquellas que el sistema programa.
• -b tmutil espera a la finalización de la copia de seguridad para acabar la ejecución.
• -r tmutil rotará las copias de seguridad de manera automática en el volumen donde se realice la misma.
• -d Permite selecionar a través de su identificador el disco donde se quiere que se realice la copia de seguridad.

Por ejemplo, supongamos que se quiere realizar una copia de seguridad del sistema en el disco con id C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83 y esperar a que esta termine:

root#tmutil startbackup -b -d C54F9BEE-AE4F-4E7B-BD9E-6AA18CDD3F83

Restaurar copias de seguridad

El comando que permite la restauración de un fichero determinado es restore src dst. Su sintaxis es la misma que la utilidad cp. Los ficheros o directorios dentro de la copia de seguridad que se quiere restaurar especificado por src y el destino especificado por dst. Por ejemplo si quisiera restaurar dentro de una copia determinada el directorio /Users/terron al directorio /tmp

root#tmutil restore
/Volumes/Backups/Backups.backupdb/menzoberrazan/Latest/Users/terron /tmp

Terminología de Time Machine

Cuando se están realizando copias usando discos locales Time Machine crea en en el mismo la siguiente estructura de directorios

Backups.backupdb
    machine_name
        copia 1
        copia 2
           ⋮
        copia n
        Latest

La terminología que usa Apple para esta estructura es la siguiente

• Al directorio Backups.backupdb se le llama backup store, que podría traducirse como almacén de copias de seguridad.
• machine_name es un directorio que contiene todas las copias de seguridad de una máquina determinada. En el caso de estar usando un disco local para almacenar las copias de seguridad, cada directorio contiene las copias de seguridad de una máquina.
• Dentro de cada máquina, se tiene cada una de las copias de seguridad que se han realizado y un enlace simbólico,Latest, que apunta a la última copia realizada.

A continuación se puede ver un ejemplo de esta estructura:

baldurgate:menzoberrazan terron$ls -al
total 8
drwxr-xr-x@ 4 terron  staff  136 28 ago 12:39 .
drwxr-xr-x+ 7 terron  staff  238  4 feb  2012 ..
drwxr-xr-x@ 7 terron  staff  238 20 may  2010 2010-05-20-225851
lrwxr-xr-x  1 terron  staff   17 28 ago 12:39 Latest -> 2010-05-20-225851
baldurgate:menzoberrazan terron$pwd
/Volumes/Backups/Backups.backupdb/menzoberrazan
baldurgate:menzoberrazan terron$

Autotools, tutorial de uso (VII): Crear librerías dinámicas con libtool

Intruducción

En enlazado o linkado dinámico es un mecanismo implementado en la mayoría de sistemas operativos actuales que permite compartir código entre diferentes procesos ejecutándose en la máquina. se implementa normalmente con ayuda de la gestión de memoria virtual del sistema. Las librerías dinámicas son los ficheros donde se almacenan este código compartido las cuales se construyen de diferente manera en función del sistema operativo.

Para intentar aislar las particularidades en la construcción de librerías dinámicas existe la herramienta libtool que se integrar de manera sencilla con las autotools para generar las librerías dinámicas de manera portable.

libtool incluye un script,libtoolize, el que va a crear una serie de scripts y macros m4 en nuestro proyecto que nos permite generar librerías dinámicas olvidándonos de las particularidades del sistema donde lo hacemos. Estos scripts son usados por autoconf y por el script de configure para generar toda la lógica necesaria. Por defecto, los ficheros y scripts que añade son enlaces simbólicos a los mismos instalados en el sistema, pero pueden copiar a nuestros proyectos si se desea.

Voy a usar de ejemplo el código del tutorial 5 que he subido a SourceForge. El código es muy simple, crear una librería de enlace dinámico libtest con tres funciones que se llaman desde el binario principal. Los ficheros configure.ac, Makefile.am y autogen.sh con las macros necesarias para que compilen la librería y funcione el enlazado dinámico serían los siguientes:

configure.ac

El fichero de configure.ac sólo necesita añadir la macro LT_INIT. Esta macro cuando se expande para formar el fichero configure, añade toda la lógica necesaria para las opciones que controlan la creación de librerías dinámicas. Esta macro puede admitir parámetros para establecer cual debe ser el comportamiento por defecto de las opciones.

 1 dnl Esto es un comentario
 2 dnl Esta macro fuerza a una versión mínima de autoconf
 3 AC_PREREQ([2.59])
 4 AC_INIT([tut5],[1.0],[cterron@users.sourceforge.net],[tut5.tar.gz],[https://sourceforge.net/p/autotutorial/])
 5 LT_INIT
 6 dnl Necesitamos el compilador de C
 7 AC_CONFIG_HEADERS([config.h])
 8 AC_PROG_CC
 9 dnl Init automake 
10 AM_INIT_AUTOMAKE
11 AC_CONFIG_MACRO_DIR([m4])
12 dnl Debe de ir al final de la plantilla. Genera el fichero config.status
13 AC_CONFIG_FILES([Makefile])
14 AC_OUTPUT

Makefile.am

En este fichero se va a definir las plantillas que nos van a generar la libreria (llamada libtest) y el binario (tut5) que usará dicha librería. Para definir la librería usamos la variable lib_LTLIBRARIES. Esta es una lista de las librerías que vamos a crear. En nuestro caso libtest.la. Ahora se definen las fuentes que se van a usar para compilar generar la librería. Puesto que el nombre es libtest.la, la variable que hay que definir es libtest_la_SOURCES, en el caso del ejemplo libtest.c. La librería tiene un fichero de cabecera que queremos instalar para que se pueda usar por parte de otros programas,para lo que usamos la variable include_HEADER con la lista de ficheros de cabecera que se desea instalar. También añadimos una variable ACLOCAL_AMFLAGS para que incluya los ficheros de macros del directorio m4. Para que el binario se compile contra la librería dinámica, lo único que hay que definir la variable tut5_LDADD indicando que utilice libtest.la. El contenido del fichero es el siguiente:

 1 # Configurado par 
 2 # Construir la librería libtest.la con las funcioens f1,f2,f3
 3 # Instala la cabecera libtest.h en el sitio correspondiente
 4 # Compila un programa test_lib que llama a dichas funciones
 5 ACLOCAL_AMFLAGS = -I m4
 6 lib_LTLIBRARIES = libtest.la
 7 libtest_la_SOURCES = libtest.c
 8 include_HEADERS = libtest.h
 9 
10 bin_PROGRAMS = tut5
11 tut5_SOURCES = testlib.c
12 tut5_LDADD = libtest.la

autogen.sh

La única modificación necesaria en este fichero es añadir la llamada a libtoolize. Cuando se ejecute, configurará el sistema con los parámetros que deseemos pasarle

1 #!/bin/sh
2 aclocal -I m4  && \
3 rm -rf autom4te.cache/ && \
4 autoheader && \
5 automake --foreign --add-missing && \
6 libtoolize  && \
7 autoconf && \
8 ./configure $@
9 

Compilar y probar el resultado

Compilar el programa es sencillo. Se puede probar sin necesidad de instalar los binarios y las librerías con ayuda de las variables de entorno.

./autogen --prefix=/usr/local
make
env LD_LIBRARY_PATH=.libs/ .libs/tut5 # En Mac env DYLD_LIBRARY_PATH=.libs .libs/tut5

Enlaces

• Documentación de libtool
• Building Libtool Libraries

Actualizado 28/08/2015

Controlar el portapapeles de OS X desde la línea de comandos

Mac OS X tiene dos comandos , pbcopy y pbpaste ,que permiten copiar manejar el portapapeles desde la línea de comandos. pbcopy leerá la entrada estándar almacenando los datos en portapapeles, mientras que pbpaste volcará el contenido del portapapeles por la salida estándar.

Por ejemplo, para copiar al portapapeles la salida del comando ls:

baldurgate:Documents terron$ls | pbcopy

Si se quiere copiar el contenido del portapaples a un fichero:

baldurgate:Documents terron$pbpaste > fichero.txt

Por otra parte, tener en cuenta que pbcopy intenta averiguar si los datos que va a copiar al portapapeles utilizan el formato EPS o RTF. En dicho caso, los copia con esos formatos. pbpaste por otra parte comprueba también los datos del portapapeles antes de volcarlos a la salida estándar: comprobará que es texto plano, sino si es EPS y por último RTF. Si los datos no están en ninguno de estos formatos, no vuelca nada.

Hay que tener en cuenta que estos dos comandos utilizan la variable de entorno LANG para determinar la codificación que deben de usar tanto en la entrada y la saluda.

Crear una autoridad de certificación con OpenSSL

OpenSSL es un conjunto de utilidades y librerías que implementan diferentes rutinas criptográficas que ayudan a implementar todo tipo de protocolos seguros. Una de las funciones incluidas nos permite crear una autoridad de certificación o CA: una entidad en la que confiamos que puede emitir o revocar certificados que se usan para tener una comunicación segura.

En esta entrada pretendo crea una CA que nos permita generar certificados que puedan ser usardos para establecer conexiones https o conexiones cifradas con utilidades como socat. Esta CA estará autofirmada y será necesario que su certificado raíz esté disponible para aquellos programas que deseen comprobar la validez de un certificado firmado por la misma. Existen paquetes como easy rsa para quien no quiera hacer estos pasos manualmente.

Crear la autoridad de certificación

Para crear nuestra CA basta con bajarse el fichero de configuración config.cnf y seguir los siguientes pasos que se dan a continuación. En la última parte del artículo se hace un recorrido por todas las opciones de dicho fichero para comprender su funcionamiento.

• Crear la estructura de ficheros

  mkdir /Users/terron/prog/ca
  mkdir /Users/terron/prog/ca/{certreqs,crls,private,certsdb}
  

• Crear el fichero de configuración y el fichero de base de datos.

  cd /Users/terron/prog/ca
  wget -O config.cnf https://sites.google.com/site/underdarktales/home/propios/config.cnf?attredirects=0&d=1
  touch index.txt
  

• Crear la clave privada y el CSR de la autoridad de certificación. El sistema pedirá el valor de ciertos atributos del certificado que están definidos en el fichero de configuración, en la sección de la política - ver al final del artículo -

cd /Users/terron/prog/ca
openssl req -new -nodes -newkey rsa:4096 -keyout private/cakey.pem -out careq.pem -config config.cnf


Las opciones que se le pasa a openssl req son las siguientes:
• -config Usa el fichero de configuración config.cnf
• -new Crea una nueva petición de CSR.
• -newkey Crea una nueva clave RSA. En este caso de 4096 bits de longitud.
• -nodes Indica que no se debe cifrar la clave privada. Recordar que para mantener la integridad de la CA, es necesario proteger esta clave al máximo.
• -keyout Ruta al fichero donde se escribirá la clave privada. Se almacenará en private/cakey.pem
• -out Ruta al fichero donde se escribirá el CSR. Se almacenará en careq.pem
• Crear el certificado autofirmado e iniciar el número de serie. Este es el certificado que debe de distribuirse a aquellos programas que quiera verificar la autenticidad de un certificado firmado por nuestra CA.

  cd /Users/terron/prog/ca
  openssl ca -create_serial -out cacert.pem -days 3650 -keyfile private/cakey.pem -selfsign -extensions v3_ca -config ./config.cnf -infiles careq.pem
  

  Con esta llamada a openssl ca se generará el fichero cacert.pem que será el que se deba de distribuir como certificado raíz de nuestra CA. Los parámetros con los que se llamarán serán los siguientes:
  • -config Ruta al fichero de configuración. En nuestro caso config.cnf.
  • -create_serial Esta opción creará el fichero serial.txt y creará un número aleatorio de 128 bits en hexadecimal que se irá incrementando con cada certificado firmado.
  • -out Ruta donde se depositará el certificado firmado por la CA. Además, creará una copia en el directorio certsdb.
  • -days Número de días en las que será válido el certificado desde el momento en que se firme. En este caso, al ser la raíz de la CA, 10 años.
  • -keyfile Clave privada de la CA que se va a usar para generar el certificado firmado.
  • -selfsign Indica que se quiere un certificado autofirmado. Esto se hace para generar el certificado raíz de la CA.
  • -extensions Utiliza la extensión de certificado X.509 definida en el fichero de configuración. En este caso se utiliza la extensión llamada v3_ca y define los atributos necesarios para que el certificado generado sea el raíz de una CA.

Generar un certificado firmado por nuestra CA

Para generar un certificado firmado por nuestra CA es necesario dar los siguientes pasos:

• Generar una clave privada y un CSR. Es importante, en el caso de querer usar este certificado para https que el campo CN que nos pregunta el comando coincida con el nombre del host o en su caso con la dirección IP, sino no funcionará.

  openssl req -new -nodes -newkey rsa:4096 -keyout server.key.pem -out server.req.pem -config config.cnf
  

• Usar el CSR (fichero server.req.pem) generado en el paso anterior para generar nuestro certificado firmado por nuestra CA. Esta orden nos mostrará los atributos del certificdado que está apunto de firmar para que confirmemos la operación.

  cd /Users/terron/prog/ca
  openssl ca -config config.cnf -days 365 -keyfile private/cakey.pem -extensions v3_req -in server.req.pem -out server.cert.pem
  

  Las opciones son similares al caso del certificado raíz, pero usando otras extensiones para el certificado X.509

Restricciones y posibles problemas

• La base de datos de texto que usa openssl ca para guardar los certificados firmados es crítica. Si se pierde peude haber problemas.
• No hay ningún tipo de soporte para concurrencia en openssl ca a la hora de firmar los certificados.

El fichero de configuración

Esta sección contiene una descripción detallada del fichero de configuración config.cnf usado como ejemplo en los pasos anteriores. Este fichero está compuesto de secciones que se utilizan en función de la utilidad de OpenSSL que se llame. Nosotros vamos a usar openssl req y openssl ca para la generación de la autoridad de certificación.

La sección de ca

La estructura de directorio que se va a usar es la siguiente. ROOT indica cual es el directorio raíz donde va a residir los ficheros de nuestra autoridad de certificación.

ROOT
    certsdb
    private
    certreqs
    crls

En el fichero de configuración se va a definir en primer lugar cuales son las opciones que se van a usar. En primer lugar vamos a definir la sección que se va a usar por defecto para defecto para generar la autoridad de certificación.

[ ca ]
default_ca = CA_default

[ CA_default ]
dir              = /Users/terron/prog/ca
database         = $dir/index.txt
new_certs_dir    = $dir/certsdb
certificate      = $dir/cacert.pem
serial           = $dir/serial
private_key      = $dir/private/cakey.pem
RANDFILE         = $dir/private/.rand
default_days     = 365
default_crl_days = 30
default_md       = sha256
policy           = policy_any
email_in_dn      = no
name_opt         = ca_default
cert_opt         = ca_default
copy_extensions  = none

[ policy_any ]
countryName            = supplied
stateOrProvinceName    = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

Esta primera sección del fichero config.cnf configura el comportamiento del comando openssl ca. Cuando se llame a dicho comando, pasándole la opción -config config.cnf buscar la sección [ ca ]. En dicha sección le hemos dicho, que por defecto, utilice la sección [ CA_default] la cual configura una serie de propiedades de la autoridad de certificación que se está creando.

En primer lugar, se definen una serie de rutas que se van a usar para almacenar los diferentes ficheros y directorios necesarios para el funcionamiento de la autoridad de certificación. Se va a referenciar a partir de la ruta raíz de la autoridad que está definida en la variable dir y en el ejemplo anterior es /Users/terron/prog/ca. Cuando openssl cuando carga el fichero de configuración realizará las sustituciones de variables necesarias por nosotros. Por ejemplo, en nuestro caso $dir/index.txt pasa a ser /Users/terron/prog/ca/index.txt.

Los parámetros que se configuran en esta sección [ Ca_default ]

• database Configura la ruta hacía la base de datos de certificados. Este parámetro es obligatorio que exista y el fichero debe de existir cuando se empieza a usar la autoridad de certificación. Puede crearse con touch. Se puede especificar la ruta desde la línea de comandos con -database.
• new_certs_dir Configura la ruta al directorio donde se almacenarán los nuevos certificados firmados por la autoridad de certificación. Este parámetro es obligatorio. Se puede tambiér especificar desde la línea de comandos con -outdir.
• certificate Ruta hacía el certificado raíz de la autoridad de certificación. Es obligatorio y también puede especificarse desde la línea de comandos con -cert.
• serial Contiene el siguiente número de serie en hexadecimal para usar en el certificado. Normalmente, en los ejemplos que he visto en Internet se solía configurar con 01, pero es mejor usar una opción cuando se crea el certificado raíz que lo autogenere.Este parámetro es obligatorio.
• private_key Esta es la clave privada de la autoridad de certificación. De su seguridad depende la integridad de todo el proceso de la autoridad de certificación.
• RANDFILE Ruta a un fichero usado para leer y escribir semillas que sirvan para la generación de números aleatorios.
• default_days Número de días en los que será válido un certificado. También puede especificarse con ayuda de la opción de línea de comandos -days.
• default_crl_days Número de días hasta que se publique la siguiente CRL
• default_md Algoritmo de huella digital que se utilizará en los certificados y en la lista de revocación de los mismos. Se puede pasar con la línea de comandos con la opción -md. Es obligatoria.
• policy Configura la sección donde se define la política que va a usar la autoridad de certificación para verificar un certificado. Esta política define qué campos deben de estar presentes y cuales deben de coincidir. Se puede pasar en la línea de comandos con -policy y es obligatoria su definición.
• email_in_dn Si este campo no está presente o vale yes el campo email, se copiará al . Está configurado para que no se copie.
• name_opt, cert_opt Estos dos campos controla los campos que se muestran cuando se pide la verificación de un certificado . Existen varios campos, pero lo razonable es dejar el campo ca_default.
• copy_extensions Controla que hacer con las extensiones que estén presente en las CSR. Si el valor es none , no se copiará ninguna de las extensiones que vengan presenten en el CSR, copy hará que se copia toda extensión que no esté en el certificado destino y copyall copia todas las extensiones del CSR. Hay que tener especial cuidado al usar las opciones copy y copyall porque puede suponer un riesgo de seguridad.

En este fragmento de fichero de configuración se ha definido una política, policy_any. La política corresponde a una serie de campos identificados por su DN. Estos campos tienen tres posibles valores:

• match El campo debe de existir en el certificado y debe de coincidir con el mismo de la autoridad de certificación.
• supplied El campo debe de existir.
• optional El campo puede existir.

Cualquier campo que no esté especificado en la política será descartado sin advertencia. En nuestro ejemplo se ha definido una política que tiene seis campos de los cuales dos son obligatorios y deben de estar presentes. El resto son opcionales.

La sección req

El comando openssl req se controla a través de las sección [ req ] del fichero de configuración. Este comando es el encargado de generar peticiones para que la autoridad de certificación nos la firme. También es el encargado de generar certificados autofirmados para usar en nuestras propias autoridades de certificación. El fragmento del fichero de configuración que se utiliza es el siguiente:

[ req ]
default_bits            = 4096
default_md              = sha256
prompt                  = yes
x509_extensions         = v3_req
distinguished_name      = req_distinguished_name
string_mask             = utf8only
[ v3_req ]
basicConstraints        = CA:FALSE
keyUsage                = keyEncipherment, dataEncipherment
[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address
countryName_default             = ES
stateOrProvinceName_default     = Madrid
localityName_default            =
0.organizationName_default      = Testing OpenSSL S.L.

Los paramétros de configuración de la sección anterior define:

• default_bits Número de bits por defecto - si no se especifica otra cosa - que tendrán la clave privada de los certificados que se generen.
• default_md Algoritmo de huella digital que se utilizará por defecto.
• prompt Si vale no, cogerá los valores por defecto de los campos que utilice el certificado del fichero de configuración. En nuestro caso vale yes porque queremos que el sistema nos pregunte por los campos que se quieren que vayan en el certificado.
• x509_extensions Este campo nos indica una sección dentro del fichero de configuración que se usará cuando se ejecutemos openssl req con la opción -x509. Esta sección especifica una serie de extensiones que se añadirán al certificado. En este caso se está especificando que utilice la sección [ v3_req ].
• distinguished_name Especifica la sección donde se definen los campos por los cuales se preguntará al usuario cuando se genere un CSR o un certificado. En este caso la sección se llama req_distinguished_name.
• string_mask indica que tipo de cadenas de caracteres se va a usar en los campos del certificado. En este caso, se indica que sólo se aceptaran cadenas UTF-8 válidas.

En nuestro caso, la extenciones que se quieren añadir al certificado son

• basicConstraints
• keyUsage

Las sección req_distinguished_name define qué campos van a ir en el certificados. Se pueden definir aquellos que se deseen, siempre que se definan a través de la sección oid_section o oid_file. Existen ya una serie de nombres definidos (con sus correspondientes identificadores) en OpenSSL. En nuestro ejemplo se han definido siete campos, y posteriormente algunos valores por defecto (nombre del campo_default)

La sección para las extensiones de la Autorida de Certificación

Para terminar, es necesario añadir una sección especial en el fichero de configuración donde se definen una serie de extensiones a los certificados X.509 que nos permitirán crear la autoridad [ v3_ca ]:

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, cRLSign, keyCertSign

Esta sección define una serie de restricciones que se usarán para generar el certificado raíz de la autoridad de certificación:

• subjectKeyIdentifier Indica como se debe de calcular el atributo Subject Key Identifier del certificado. Debe de dejarse en el valor de hash.
• authorityKeyIdentifier Este campo configura como debe de calcularse el atributo Authority Key Identifier, que sirve para identificar la autoridad de certificación que ha firmado un certificado. Este campo indica que se usará para indentificar a la misma. En ecaso del ejemplo se usa el keyid - el identificador de la clave de la autoridad de certificación y issuer que hace que se utilicen los campos Subject y el número de serie del certificado de la CA. Aunque esta configuración puede presentar un problema en caso de que tenga que rehacerse la CA con la misma clave privada.
• basicConstraints Este es una extensión que indica que el certificado puede actuar como una autoridad de certificación y permite restringir la longitud de la cadena de certificación. En este caso se le está indicando que el certificado si es una CA y que es crítica, es decir, que sino puede acceder a ella no puede ser procesado
• keyUsage Esta extensión determina cuales son los usos apropiados de la clave de la CA: Al menos debe ser capaz de firmar la lista de revocación de certificados (cRLsign) y los certificados (keyCertSign). En el caso de que esta extensión no esté presente, se permiten todos los usos de las claves.

Referencias

• Openssl.conf Walkthru
• Creating a CA
• Creating an SSL Certificate of Authority
• OpenSSL Certificate Authority
• Certificate signing request (CSR)
• Certificate Revokation List
• X.509
• x509v3_config
• Internet X.509 Public Key Infrastructure

---