Hi Liste, ich versuche seid einigen Tagen mein Sendmail und qpopper mit der TLS Verschlüsselung ans laufen zu bekommen. Auf dem Server laüft Suse 8.0 mit Sendmail 8.12.3 und qpopper 4.0.3-147. Ich möchte Sendmail für eingehende Verbindungen verschlüsselt herstellen. Sprich der Server laüft als Mailserver und wenn sich ein Client anmeldet um Mails zu versenden soll dies nur über den gesicherten Smtp Kanal gehen. In meine linux.mc habe ich folgendes hinzugefügt: define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnl define(`confCACERT_PATH', `CERT_DIR')dnl define(`confCACERT', `CERT_DIR/CA.cert.pem')dnl define(`confSERVER_CERT', `CERT_DIR/MY.cert.pem')dnl define(`confSERVER_KEY', `CERT_DIR/MY.key.pem')dnl define(`confCLIENT_CERT', `CERT_DIR/MY.cert.pem')dnl define(`confCLIENT_KEY', `CERT_DIR/MY.key.pem')dnl bei einer localen telnet verbindung auf Port 25 und dem aufruf Ehlo localhost bekomme ich auch 250 STARTTLS angezeigt. Auch der aufruf STARTTLS Antwortet mit 220 2.0.0. Ready to start TLS. Qpopper habe ich eine zusätzliche conf datei gegeben in der folgendes steht: set tls-support =alternate-port set tls-version =default set tls-server-cert-file =/etc/mail/certs/MY.cert.pem die dateien /etc/services und /etc/inetd.conf habe ich auch angepasst! Bei einer connection mit einem Mailclient bekomme ich in /var/log/mail folgende meldung: --snip-- Jul 4 22:37:28 kleinerkoch sendmail[17811]: g64MbSaA017811: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch sendmail[17815]: g64MbSaA017815: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch sendmail[17813]: g64MbSaA017813: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch sendmail[17817]: g64MbSaA017817: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch popper[17819]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] Jul 4 22:37:28 kleinerkoch popper[17820]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR Unknown command: "\200f^A\200^A". [pop_get_command.c:152] Jul 4 22:37:28 kleinerkoch popper[17820]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] Jul 4 22:37:28 kleinerkoch popper[17821]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] Jul 4 22:37:28 kleinerkoch popper[17822]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] #Diese meldung kommt zwischen drin des öfteren Jul 4 22:48:07 kleinerkoch sendmail[17884]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1/SSLv3, verify=NO, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168 Jul 4 22:48:07 kleinerkoch sendmail[17883]: STARTTLS=client, relay=localhost.kleinerkoch.de., version=TLSv1/SSLv3, verify=FAIL, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168 --snip-- ich vermute das irgend etwas mit den Zertifikaten nicht stimmt! Diese habe ich so in den Verzeichnissen wie es in den conf files geschrieben ist! Ich hoffe mir kann jemand weiter helfen! Danke Micha Siebenich
Hallo Micha,
Jul 4 22:37:28 kleinerkoch sendmail[17811]: g64MbSaA017811: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch sendmail[17815]: g64MbSaA017815: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch sendmail[17813]: g64MbSaA017813: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch sendmail[17817]: g64MbSaA017817: ruth.kleinerkoch.de [192.168.0.23] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Jul 4 22:37:28 kleinerkoch popper[17819]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] Jul 4 22:37:28 kleinerkoch popper[17820]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR Unknown command: "\200f^A\200^A". [pop_get_command.c:152] Jul 4 22:37:28 kleinerkoch popper[17820]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] Jul 4 22:37:28 kleinerkoch popper[17821]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794] Jul 4 22:37:28 kleinerkoch popper[17822]: (null) at ruth.kleinerkoch.de (192.168.0.23): -ERR POP EOF or I/O Error [popper.c:794]
das sieht mir eher nach nem RELAY-Problem aus, check das mal. Gruß Thorsten Hantke www.providerprogramm.de
Hi,
das sieht mir eher nach nem RELAY-Problem aus, check das mal.
eins kann ich noch hinzufügen. Vor den experimenten mit SSl und TLS ging Sendmail und Qpopper wunderbar. Muss man vielleicht an der /etc/mail/access Tabelle etwas ändern um verschlüsselte Verbindungen anders zu definieren? Aber bei pop Verbindungen muss er ja nicht Relayen!? Da geht es ja nur darum das die Verbindung hersestellt wird der Benutzer authentifiziert wird und die Mails überträgt. Vielleicht könnte jemand mal schreiben wie genau diese Zertifikate erstellt werden. Den da bin ich bis jetzt noch ziemlich unschlüssig da es zwar auf vielen HPs beschrieben wird, aber auf jeder ein bisschen anders. Wie wichtig ist es den hierbei die Zertifikate ohne Passwort zu erstellen? Wie bekommt man es den aus den Zertifikaten heraus? Grüsse aus FFM Micha SIebeneich
On Fri, 5 Jul 2002, Micha Siebeneich wrote:
Hi,
das sieht mir eher nach nem RELAY-Problem aus, check das mal.
eins kann ich noch hinzufügen. Vor den experimenten mit SSl und TLS ging Sendmail und Qpopper wunderbar. Muss man vielleicht an der /etc/mail/access Tabelle etwas ändern um verschlüsselte Verbindungen anders zu definieren? Aber bei pop Verbindungen muss er ja nicht Relayen!? Da geht es ja nur darum das die Verbindung hersestellt wird der Benutzer authentifiziert wird und die Mails überträgt. Vielleicht könnte jemand mal schreiben wie genau diese Zertifikate erstellt werden. Den da bin ich bis jetzt noch ziemlich unschlüssig da es zwar auf vielen HPs beschrieben wird, aber auf jeder ein bisschen anders. Wie wichtig ist es den hierbei die Zertifikate ohne Passwort zu erstellen? Wie bekommt man es den aus den Zertifikaten heraus?
Morgen Micha, für das Erstellen der Zertifikate habe ich im Web eine sehr gute Anleitung gefunden. Habe mir aber für den Privatgebrauch nur den Text heruntergezogen und leider _nicht_ die URL. Der/die Verfasserin möge mir also dies bitte nachsehen und - noch besser - die URL dazu angeben. Das war die erste Anleitung, mit der es bei mir funktioniert hat, allerdings mit Postfix. Wichtig ist noch "-nodes" habe ich auch in dem Skript bei "-sign" ergänzt. Und das Skript heisst glaube ich auch CA.sh. Viel Erfolg Joachim +++++++++++++++++++++++++++++++++++++++++++ Step 2: Which certificates are required? CERT 1: CA cert (cacert.pem) We need a cert from a Cert-Authority that we can refer to when a client wants to validate the cert that we issued from our Postfix-server. There are two possibilities and it all boils down that "It's a matter of trust". Become your own CA If you are a private user and simply want to enjoy encrypted communication, but don't want to pay for a cert, you can become your own CA. You'll only will use it for yourself and hey who shouldn't trust yourself more that you. This HOWTO will show you how to do that. Get an official certificate If you will use your server for business purposes (ISP, etc.) you should go and get a valid cert for your server from an offical CA. Your customers will apprechiate. Meanwhile this should not keep you from reading on and building your own CA authority certificate for testing purposes. CERT 2: public server.cert (newcert.pem) We will need to issue a certificate when we establish the connection. This certificate is the public server.cert. CERT 3: private server cert (newreq.pem) What do we need this for? Anyway, it's the private server cert. Step 3: Build certificates for TLS use When a TLS connection is being established the host establishing the connection has to validate itself. This is because someone else could hijack the connection and establish an encrypted connection. The remote host probably wouldn't notice and pass sensible information. Therefore certificates are used to provide unique information that proves that the host encrypting the communication really is the host your client wants to talk to. You are right when you argue that anyone even a hostile server could issue a certificate if it wasn't for that little detail we left out: Each certificate that is issued provides information about an authority that will validate the cert that is issued when an TLS connection is established. Now that you understand the concept you'll understand what we need: RH 7.x Users On RedHat machines openssl has its configuration file for creating certs in /usr/share/ssl. So we go there and edit that file first as it carries the default values that will be offered to us later. You can skip this section, but don't complain when you mistype your values and must start the whole script again. ;-) [root@example.com]# cd /usr/share/ssl/ [root@example.com]# vi openssl.cnf edit countryName_default and 0.organizationName_default and provide values that make sense to your setting. This HOWTO will use Germany (DE) and HOWTO as values. countryName_default = DE 0.organizationName_default = HOWTO then uncomment organizationalUnitName_default and add a value. We will use Mailserver in this HOWTO. organizationalUnitName_default = Mailserver add the lines commonName_default (must be the name of your Mailserver!) and emailAddress_default and provide values specific to your setting. Our Mailservers hostname is mail.example.com and postmaster@example.com is in charge. commonName_default = mail.example.com emailAddress_default = postmaster@example.com That's it and it will save us a lot of typing as we will build not only one cert. Save the file and read on as we will have to edit yet another file. Consider this: Usually certs are crypted. That's a good idea when you take them along with yourself and the disc you have it on gets lost. It won't be of any use to the finder unless that person also knows your secret passphrase... But then if you don't take it with you, but leave it on a server this feature can become a real problem to the availabilty of your service. Why? Well, any time you restart the server and the server wants to get its hand on the cert, the cert wants to be given the secret passphrase and the server hangs in there waiting to pass that task on its start list. And it waits and waits and waits... until you enter the secret passphrase at the command prompt. The bottom line is: No passphrase, no service. So we will not create certs with secret passphrases, as we will not always be available when the server needs to be restartet or starts itself, say after a power failure. In order to have certs that aren't crypted we will have to add a parameter to the script that we run when we create a cert. So let's cd to the directory that holds the script and create a backup first before we edit it. [root@example.com]# cd misc/ [root@example.com]# cp CA CA_nodes [root@example.com]# edit CA_nodes Note Either it's CA or CA.pl. This depends on your RedHat distribution. Both scripts will help you generate certs. Search for # create a certificate and add -nodes to the line below that begins with $REQ. When your done with this search for # create a certificate request and do the same again. When your done it should look like this: -newcert) # create a certificate $REQ -new -nodes -x509 -keyout newreq.pem -out newreq.pem $DAYS RET=$? echo "Certificate (and private key) is in newreq.pem" ;; -newreq) # create a certificate request $REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS RET=$? echo "Request (and private key) is in newreq.pem" ;; That's it for preparations. Let's create the certs. Step 3.1: Generating the CA certificate The first cert we will create is the Authority cert. We do this by calling the CA script and telling it that we want it to create a new CA: [root@example.com]# ./CA_nodes -newca CA certificate filename (or enter to create) MAKING CA CERTIFICATE ... Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key ................++++++ ......................++++++ writing new private key to './demoCA/private/./cakey.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [DE]: State or Province Name (full name) [Germany]: Locality Name (eg, city) []:Munich Organization Name (eg, company) [ExampleOrganisation]: Organizational Unit Name (eg, section) [Mailserver]: Common Name (eg, your name or your server's hostname) [mail.example.com]: Email Address [postmaster@example.com]: Step 3.2: Generating the server certificate request Then we will create the server cert request that will be signed by the CA Authority: [root@example.com]# ./CA_nodes -newreq Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key .........................++++++ .............++++++ writing new private key to 'newreq.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. ----- Country Name (2 letter code) [DE]: State or Province Name (full name) [Germany]: Locality Name (eg, city) []:Munich Organization Name (eg, company) [ExampleOrganisation]: Organizational Unit Name (eg, section) [Mailserver]: Common Name (eg, your name or your server's hostname) [mail.example.com]: Email Address [postmaster@example.com]: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:certpass An optional company name []: Request (and private key) is in newreq.pem Step 3.3: Signing the server certificate Finally we sign the server cert request with our own CA cert: [root@example.com]# ./CA_nodes -sign Using configuration from /usr/share/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'DE' stateOrProvinceName :PRINTABLE:'Germany' localityName :PRINTABLE:'Munich' organizationName :PRINTABLE:'ExampleOrganisation' organizationalUnitName:PRINTABLE:'Mailserver' commonName :PRINTABLE:'mail.example.com' emailAddress :IA5STRING:'postmaster@example.com' Certificate is to be certified until Mar 15 07:45:17 2003 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y ... Signed certificate is in newcert.pem Let's review what we have generated. newreq.pem This is the private SERVER CERT. We generated it in order to request an CA to sign it. It contains our private key. newcert.pem That is your public SERVER CERT. It has been signed by a CA in this case ourselves. demoCA/cacert.pem This is the CERT of the CA Authority. We created it when we made ourselves a CA.
participants (3)
-
Joachim Kieferle
-
Micha Siebeneich
-
T. Hantke