openssl x509 -in cert.crt.pem -inform PEM -out cert.crt.der -outform DER

Nos devolvera un archivo.crt.der (que parece que es lo mismo que un .crt) y si lo queremos al reves:

$ openssl x509 -in cert.crt.der -inform DER -out cert.crt.pem -outform PEM

Extraido de esta web

/etc/proftpd.include

Una vez dentro, entre <VirtualHost> y </VirtualHost>, se ha de añadir:

<IfModule mod_tls.c>

TLSEngine on

TLSRequiried on

TLSLog /var/log/proftpd/tls.log

TLSRSACertificateFile /etc/httpd/conf/ssl.crt/server.crt

TLSRSACertificateKeyFile /etc/httpd/conf/ssl.key/server.key

TLSCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt

</IfModule>

Con esto tenemos ftp bajo ssl

Es tan sencillo como ir a la carpeta de control del qmail:

find / -name “control”

Os da la ruta de la carpeta y copiais el certificado generado anteriormente (y en un solo archivo) dentro de la carpeta con el nombre server.pem

Lo remarco en negrita porque sino estuvieramos en plesk no hubiese tenido problemas de “conceptos”

En Plesk tienes una opcion de añadir certificados a los dominios que tienes. De una manera sencilla y muy muy transparente, PERO, añades certificados a los dominios (o subdominios). Lo que yo queria es que cuando me conectara con el thunderbird a mi servidor de correo la conexion fuera ssl, y ademas no apareciera el molesto mensaje de que si acptaba el certificado.

Si el certificado es autofirmado tienes que decirle una vez que si, y que memorize la accion, asi no tiene que molestar cada vez. Si el certificado lo ha firmado verisign, comodo, etc etc entonces no hace falta nada de esto, te lo acepta automaticamente porque es una CA autorizada.

El problema es el planteamiento. Mi servidor de mail se llama mail.dominio.es, por tanto diriamos que es un “subdominio” de dominio.com.

Cuando solicite el certificado a comodo lo hice para dominio.com, y como no se integran los subdominios en los certificados, mail.dominio.com no era “acpetado” dentro del certificado, y siempre me salia la advertencia, y aunque le dijera que confiara, siempre me lo preguntaba.

Me di cuenta de que el certificado que me salia era de courier-imap. Un certificado que se debe instalar cuando instalas el courier y supongo que lo pondran para poder tener conexion ssl sin necesidad de que tu crees ningun certificados, ni te metas en esos “marrones” .

Para poder cambiar el certificado default de courier te tienes que conectar a la consola del servidor (en este caso el mio es CentOs) y proceder asi:

-en la carpeta /usr/share/courier-imap/ tenemos imapd.pem y pop3d.pem.

estos son los certificados default

-substituimos imapd.pem por nuestro certificado (autofirmado o firmado por una CA) de la siguiente forma:

-en un mismo archivo primero ponemos el certificado nuestro y luego la clave RSA. Quedaria tal que asi:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

-luego le damos persimos 600 a imapd.pem y listos

metodo extraido de esta web

Ahora mismo lo que nos saldra cuando nos conectemos con thunderbird al servidor es nuestro certificado. Que en el caso de ser autofirmado, podemos crear el archivo crt de nuestra CA y añadirlo a los certificados de confianza de thunderbird para que no nos “moleste” con su advertencia.

Depues de analizar lo que he tenido que hacer, he pensado que puede que se pueda hacer desde el panel del plesk, evitandonos entrar en consola, pero no lo he comprobado.

La manera seria la siguiente:

Partiendo de la base de que un certificado solo puede ser de un dominio o subdominio, sin englobar a los demas, nosotros creamos un subdominio en plesk llamado mail.dominio.com.

Pedimos un certificado (o lo autofirmamos) y se lo añadimos a este subdominio, mail.dominio.com

Cuando nos conectemos con el cliente web deberia salir el certificado del subdominio, que en este caso el subdominio es igual al nombre del servidor de correo.

Lo que no se es si se puede hacer (a nivel de dns) llamarle igual a la entrada MX que a un subdominio.

Es algo que deberia probar

———————————————————————————–

EDITO:

Acabo de instalar un certificado para webmail.dominio.com y en cuanto me he conectado por el firefox me ha autorizado el certificado (porque era firmado por una CA autorizada) y todo perfecto.

webmail.dominio.com no es un subdominio. Almenos lo que se es que en mis entradas de la DNS tengo una llamada webmail.dominio.com apuntando hacia la ip de mi servidor.

Con esto puedo suponer que lo que he dicho arriba puede ser viable, el unico problema que tengo ahora, es que el certificado lo he instalado en el dominio dominio.com y es para webmail.dominio.com. Esto quiere decir que si accedo por http a dominio.com el certificado no me servirá.

Supongo que para poder tener un certificado para cada servicio (webmail, ftp, mail, http, … ) tengo dos opciones:

1.-ir buscando los programas que me dan estos servicios (courier, proftp, apache, … ) y configurarles manualmente un certificado para cada uno

2.-el metodo de crear subdominios desde plesk, para que asi todo se haga desde plesk y no tenga que conectarme por conola y “trastear” el servidor

Lo que aun no tengo claro es que diferencia hay entre un subdominio creado desde plesk y una entrada en las dns del tipo web.dominio.com apuntando a la ip de mi servidor.

Para ilustrar estoq ue no tengo claro, hay un ejemplo real que sera facil de entender.

Tenemos un servicio en 1&1 de hosting, que te da un dominio y 1000 subdominios. Pero que al no haber contratado un vps o servidor, no tengo un servidor dns propio, sino el de 1&1.

En este caso si quiero tener un ftp, creo un subdominio llamado ftp.dominio.com que apunta hacia una carpeta del hosting, o hacia otro ordenador de la red.

El otro caso es que yo tengo un vps, con su servidor dns. Creo la entrada ftp.dominio.com apuntando a la ip de mi servidor, o a otro ordenador de la red.

En los dos casos cuando en un navegador o programa ftp ponga ftp.dominio.com me conectare a ese ftp.

El primer caso lo he hecho con subdominios y el segundo con entradas de dns, por tanto:

que diferencia hay entre un SUBDOMINIO y una ENTRADA DNS?

Si empezamos leyendonos el manual nos explica que elementos vamos a instalar y para que sirve cada elemento.

De momento yo tengo un servidor de correo funcional en que los usuarios que se conecten fuera de la red local el usuario y la contraseña iran encriptadas en 64 bits.
Está también configurado para que no sea Open Relay y que pueda alojar dominios virtuales. Yo concretamente tengo dos dominios, erikcrane2000.es y erikcrane.es.

El manual empieza instalando las librerias Sasl y el MDA Cyrus Imap. Con esto podemos dar de alta a usuarios en la base de datos sasldb y podemos crear buzones de correo para dichos usuarios.

Una vez realizado esto pasamos a la instalación de Postfix, en la que con telnet comprobaremos la funcionalidada de este.

Es poco interesante que me ponga a explicar los pasos que hay que seguir para poder hacer todo esto, ya que en el manual te lo explican muy bien, y además se mota la molestia de explicar el porque de cada cosa.

Lo que yo voy ha hacer es repasar el manual y explicar aquellas cosas que a mi me costaron de entender. Así si algún dia vuelvo a meterme, que no tenga que volver a seguir el mismo proceso de aprendizage.
También pondré links a otros manuales con los que me he ido topando y son de interés.

———————————————————————————

El primer problema que voy a comentar no es en si un problema de comprensión, ni de instalación, … , sinó de mala suerte.

Yo me instalé la versión cyrus 2.1, tal como ponia el manual, pero claro el manual es del 2004 o el 2006, y ya van por la versión cyrus 2.2.

El problema que tenia era que cuando entraba en cyradm no podia crear mailboxes que estuvieran en otro dominio que no fuera el default.

A efectos practicos cuando yo ponia:

cm user.paco@erikcrane2000.es

Me daba un error de permisos, createmailbox: Permision denied. Esto me pasaba siempre que ponia @ en el nombre de algun buzon.

Después de buscar y buscar llegué a la conclusión de que podia ser que estuviera mal instalado.

Una vez lo desinstalé y instalé una versión superior todo fué correcto.

Pasado esto vamos continuando con el tutorial sin ningún problema.

Llegamos al apartado de instalar Postfix y de que Postfix se comunique con Cyrus via LMTP.

En este punto nos hemos de asegurar de que tanto Postfix como Cyrus puedan escribir sobre el socket lmpt.

También se han de añadir los usuarios cyrus y postfix al grupo sasl para poder encritptar el usuario y el password cuando los usuarios se conectan al servidor desde fuera de la red local.

El tema de dominios virtuales es muy interesante verlo, porque debido a que tener una ip fija es carillo, siempre podras tener mas d eun dominio en tu servidor.

El último problema que se me ha presentado ha sido con hotmail.

Una vez que he acabado de configurarlo me conecto con un cliente de correo (outlook express) y hago las pertinentes pruebas para ver si los correos de los dominios que tengo pueden enviar y recibir correo, tanto desde dentro de la red local como desde fuera.

Como es lógico en las pruebas de los mails no suelo poner una cadena larga de texto, pongo “hola” o “prueba”. El problema viene cuando intentas enviar una mail a una cuenta de hotmail. Estos tienen unos filtros antiespam que me tiran el mail “patras”. Si escribo un mail mas largo y con asusnto me lo deja pasar.

Lo que yo supongo es que hasta que no tenga configurado un poco mas de seguridad tendré estos problemas. Porque he hecho la misma prueba desde un servidor con Qmail y si me lo deja pasar. El servidor de Qmail ya viene configurado con anti-smap y esas cosas.

De momento eso es todo, aqui abajo dejo unos links de interés y me pondré con la instalació de los certificados ssl para el servidor.

Después de descargarme los tutoriales (unos 5 o 6) empezé a mirarmelos y al tajo!!!

Esta es una configuración muy básica sin ningún tipo de seguridad, la seguridad la dejo para la segunda parte.

Básicamente he tocado dos ficheros, el /etc/bind9/name.conf.local y el /etc/bind9/db.<nombre del dominio>

Por cierto, tampoco me he mirado la configuración de la zona reverse forward, de momento no me es necesario y también lo dejaré para la parte segunda.

Los ficheros me han quedado asi:

name.conf.local


//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
//
zone "dominio.es" {
type master;
file "/etc/bind/db.dominio.es";
};

db.<dominio>:


;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA dns1.dominio.es. adim.dominio.es. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS dns1.dominio.es.
@ IN NS dns2.dominio.es.
dns1 IN A 1.1.1.1
dns2 IN A 1.1.1.1
@ IN A 1.1.1.1
@ IN MX 0 1.1.1.1
mail IN A 1.1.1.1

En el primer fichero de le estamos declarando el dominio para el que el servidor sera master, en este caso dominio.es, y que la configuración de la zona de nombres del dominio estará en el fichero /etc/bind9/db.dominio.es

En el fichero del dominio encontramos un primer registro con @ IN SOA <nombre del servidor dns> <e-mail>.

El @ creo que es el nombre del dominios, en este caso dominio.es. Con esta linia lo que creo es que esta diciendo que en el dominio.es hay un dns1.dominio.es que es el que resolverá los nombres de ese dominio.

Digo que “creo”, porque aun no he profundizado mucho en el tema.

Las siguientes lineas se pueden leer si se sigue una lógica:

1.-<@ IN NS dns1.dominio.es.> dominio.es apunta al servidor de nombres que puede resolver el nombre en una ip. El registro es NS porque apunta hacia un servidor de nombres. (Hay que fijarse que si se apunta hacia un nombre se pone un . al final del nombre)

3.-<dns1 IN A 1.1.1.1> el alias dns1 (es una alias del dominio dominio.es que para ti significa que es el servidor de nombres) apunta a la ip del servidor donde esta alojado.

5.-<@ IN A 1.1.1.1> dominio.es apunta a la ip del servidor donde esta alojado. (Si os fijais el registro A se utiliza para apuntar hacia una ip)

6.-<@ IN MX 0 1.1.1.1> dominio.es apunta haci la ip del servidor de correo donde está alojado este servidor. (MX se utiliza para decir que apunta hacia un servidor de correo). El 0 es la prioridad que tendrá ese servidor de correo frente a otros servidores. Como solo tengo uno le pongo el valor que quiero, pero le he puesto 0 porque es el que tiene la prioridad mas alta.

7.-<mail IN A 1.1.1.1> el alias mail apunta a la ip donde esta alojado el servidor de mail. (mail es solo un alias que le pongo para cuando yo configure un servidor de correo y le tenga que decir a mi cliente de correo como se llama mi servidor de correo, no tenga que introducir una ip, simplemente un nombre canónico que es más fácil de recordar)

Bueno esto es todo lo que he aprendido hasta ahora. No se si todo lo que pongo es correcto, solo pongo lo que yo he entendido.

Bueno vamos al tajo.

Este seria un esquema muy esquemático de como es un envio de un mail:

• a@a.com envia un mail con su MUA (mail user agent)

el MUA se encarga de interactuar con el usuario para que este le diga que mail quiere enviar y le de la orden de envio.

• el MUA utiliza al MSA (mail submission agent) para cotactar con el MTA (mail transfer agent), o como coloquialemente se le conoce al servidor de correo SMTP

el MSA es un intermediario entre el cliente y el servidor y transfiere la información entre estos dos mediante el protocolo SMTP. El MSA suele incluirse en el MUA

• el MTA del cliente a@a.com envia el mail al MTA de b@b.com (el remitente del mail)

el MTA del cliente busca donde esta b@b.com. Para hacer esto consulta al servidor DNS del dominio b.com donde optiene el registro MX que indica donde está el servidor de correo (o el MTA de b@b.com)

• cuando el MTA de b@b.com tiene el mail contacta con el MDA (mail delivery agent) de b@b.com

el MDA es el encargado de guardar el mail en una casilla si la cuenta de destino está en el equipo local y si está en otro equipo envia el mail por SMTP. A parte de esto tiene más funciones, filtro anti-spam, antivirus, …El MDA suele estar integrado en los MUAs o en los MTAs (como por ejemplo en Sendmail)

• ahora es cuando viene el usuario del mail b@b.com y decide mirar si tiene correo nuevo.

para eso con su cliente de correo (pop3/imap) se conecta a su MDA para ver si tiene correo. Si el protocolo usado por el cliente es pop3 utiliza el MUA del cliente b@b.com para bajarse el mail del servidor de correo y alojarlo en el disco duro del usuario. Por lo contrario, si utiliza el protocolo IMAP el cliente de correo hace una copia del mail y lo guarda en el disco duro del usuario. El cliente de correo suele ser el MUA

Cabe decir, que el MUA también suele ser el cliente de correo, incluso creo que hoy en dia siempre es el cliente de correo (es  un concepto que aun no tengo muy claro)

Al fin y al cabo el esquema acabaria siendo así:

MUA (a@a.com)—>MTA(a.com)—->MTA(b.com)—->MDA(b.com)—->MUA(b@b.com)

Realmente el MTA y el MDA son el mismo servidor, solo que el MTA es el servidor de salida y el MDA el de entrada. Es decir, cuando a@a.com envia un mail el MTA de a.com envia ese mail hacia el MTA de b.com. La comunicación se realiza mediante SMTP.

En cuanto el MTA de b.com recibe el mensaje lo pone a disposición del MDA de b.com, que es donde el usuario b@b.com irá a buscar el mensaje.

El MUA de b@b.com se conectará mediante pop3 o imap a su servidor de correo (MTA) para leer su mensaje.

Esta última explicación seria la versión simplificada de la de arriba.

Para aclarar mejor los conceptos pondré ejemplos de nombres de programas que sean MUA, MTA, MDA, ….

MUA–> link

MTA–> link

MSA–> msmtp, nbsmtp

Clientes pop3/imap–> link

Páginas de mucho interés:

Cliente de correo
Email
Agente de Transporte de Correo
Registro MX
mail_internet
unix-users
www.monografias.com