| Linode Forum https://forum.linode.com/ |
|
| Postfix can't find saslauthd https://forum.linode.com/viewtopic.php?f=11&t=4319 |
Page 1 of 1 |
| Author: | mattr [ Sat Jun 13, 2009 12:59 pm ] |
| Post subject: | Postfix can't find saslauthd |
Hello, I installed postfix/dovecot and started with admin via webmin. Unfortunately could not email outside my own server due to postfix's helpful initial settings which disallow that, leading to relay access denied messages. What I need is to make it possible to send email from outlook (just one pc for now) via postfix to the world, preferably with my ordinary unix account login/password. Oh, I'm on ubuntu 8. This is really hard. The merry go round I took led me to install TLS (with a self generated key), SASL, saslauthd (I apt-get sasl2-bin), etc. (I also tried a hash briefly which didn't work). Anyway, I have them all installed. Also dovecot seems to work fine out of the box, TLS too I think. BUT, postfix mail.info log says: Jun 14 01:38:12 telebody postfix/smtpd[26399]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Jun 14 01:38:12 telebody postfix/smtpd[26399]: warning: xxxxxxxxxxxxx.userreverse.xxxxxx.xx.jp[xx.xx.xx.xx]: SASL LOGIN authentication failed: generic failure master.cf has (I had to uncommend the -o part): smtp inet n - y - - smtpd -o smtpd_sasl_auth_enable=yes /etc/postfix/sasl/smtpd.conf has: (the commented ones don't work either, these are from posts I found) pwcheck_method: saslauthd mech_list: PLAIN LOGIN #saslauthd_path: /var/run/saslauthd saslauthd_path: /var/run/saslauthd/mux #saslauthd_path: /var/spool/postfix/var/run/saslauthd/mux I have been able to do a login via telnet to port 25 within my own server, and posted a base64 of the login/password which at least gave me an encrypted response. Can anyone provide insight into what's going on? I saw somebody ran strace on master a long time ago and found undocumented path for mux.. I'm not so skilled at that. Also don't have the source so can't run the example server as su as they say, just did apt-get install. Help! Best regards, Matt |
|
| Author: | db3l [ Sat Jun 13, 2009 5:43 pm ] |
| Post subject: | Re: Postfix can't find saslauthd |
mattr wrote: What I need is to make it possible to send email from outlook (just one pc for now) via postfix to the world, preferably with my ordinary unix account login/password. Oh, I'm on ubuntu 8.
(As I'm about to post this I'm realizing it grew rather large, so here goes...) Since it's not absolutely clear, I'm assuming that your PC is back at home or work or something, and thus from your Linode's perspective is an "external" host that is trying to use it to send mail, correct? First, I can sympathize with the complexity - jumping right into TLS (transport layer security) with its certificates, keys, and probably a bunch of new concepts has a rather steep learning curve. The good news is that your TLS knowledge will translate to many other applications beyond email. While I haven't done authentication with Postfix before, I might in the future, so took a peek. I suspect your specific error is either related to the fact that Postfix run's chroot'd beneath /var/spool/postfix so some of the paths you are seeing actually have to be relative to that root, or that you haven't made postfix part of the sasl group to be permitted to connect to the saslauthd socket. Taking one step back, it may help your mental picture to clearly separate TLS and SMTP SASL as two independent features. TLS can protect the raw network connection, including authentication of each party, but it applies to the raw network data. SASL is authentication at the application layer that the SMTP server uses to identify the user enqueuing a message, providing one or more ways to exchange the authentication information. That exchange can occur over a normal or TLS-protected connection. The reason you often see them combined is that once you have a secure network connection, the application can be much less concerned with the security of data, such as passwords, that it sends across the link. So having the TLS session lets you use simpler application layer schemes (like SASL's PLAIN) without worry. But the two parts are still quite independent. Further complicating the SASL side is that actual implementation of the SASL authentication methods can be internal to an application (such as Postfix) or provided by an external server (such as saslauthd), so there's yet another level of flexibility/complexity. saslauthd, in turn, supports various backends, such as its own local database file, or "pam" to tie into the standard Linux authentication. And of course, in your setup, you actually have two applications (Postfix and Dovecot) that are doing authentication independently, which may or may not share a mechanism. Since it sounds like you've got TLS functioning (self-signed is fine as long as you have control over both server and clients, not to mention cheaper), I'll give a shot at the SASL side of things. Starting from a fresh Postfix setup on my Ubuntu 8.04 system, I was able to get SASL based authentication working with saslauthd (sans any TLS) by: SASL:
Code: ** > telnet xxx 587 In particular, note the "250-AUTH" initial response. Per PLAIN authentication my submission was a base-64 encoding of a utf-8 encoding of username+nul+username+nul+password (the first username is who I want to act as, the second is the authentication user). Since we've restricted ourselves to plain text authentication methods, this is not a configuration you'd want to use without TLS like I am here. However, if TLS is an issue (either unnecessary complexity, or a problem for some of your clients), you could decide to switch to a better authentication scheme and remove TLS. One downside to this is that you won't be able to authenticate against the local system accounts, but will have to use a separate SASL database. If you're likely to have clients that wouldn't otherwise need a full account on the system, this may actually be neater, as you don't need wasted system accounts just for SASL authentication. It can also do away with the need to run a separate saslauthd daemon. For example, if you completely remove any /etc/postfix/sasl/smtpd.conf file, then by default Postfix will internally use its SASL libraries to authentication. Postfix on my Ubuntu system is built against both Cyrus and Dovecot libraries (you can check with "postconf -a"). The default is Cyrus (smtpd_sasl_type setting), but if you are maintaining a Dovecot authentication database, you could opt to use that instead. But for Cyrus, it will look for an /etc/sasldb file. Since Postfix is chroot'd, this file is actually /var/spool/postfix/etc/sasldb. By default, you also need to make sure that the domain you use for accounts in this file matches your fully qualified hostname in Postfix (which can be queried with "postconf -h myhostname"). Although you'll no longer run the saslauthd daemon, you'll still want the sasl2-bin package to have the tools to manage the password file. To set this up, given the result of the above configuration, I:
Code: > telnet xxxxx 587 and authenticates directly against the users in your sasldb database which can be maintained independently of the rest of the system. Of course, there are more permutations on all of this, but hopefully the above will give you a starting point from which you can explore the various options. -- David PS: Just for the record, if you just want to solve your single PC problem for testing independent of all the TLS/SASL stuff, you can add the address of your PC to the mynetworks parameter in /etc/postfix/main.cf (as a x.y.z.w/32 host address) to permit the relaying temporarily. Just remember to keep it up to date if you have a dynamic address that changes. |
|
| Author: | mattr [ Mon Jun 15, 2009 8:05 am ] |
| Post subject: | [SOLVED!] Postfix can't find saslauthd |
Dear David, Thank you so much! That is a fabulous explanation!!!!! I can now send email from Outlook on my work PC via postfix to the world. But, I'm not sure it is actually encrypting the traffic. NOTE! After doing this writeup I SOLVED it. I was able to see that TLS is being started by adding this to main.cf: smtpd_tls_loglevel = 2 Which in the mail.info log shows: setting up TLS connection from MYIP Anonymous TLS connection established from MYIP: TLSv1 with cipher RC4-MD5 (128/128 bits) xxxxxxxx: client=MYIP, sasl_method=LOGIN, sasl_username=mattr So I think it is solved. But I leave my post here for anyone who has this problem in the future. I will briefly say what I did to make it work and what is different from how you posted. After reading your post, I did: - changed method from shadow to pam (For now I am using pam, not a separate sasldb, for authentication.) - in /etc/postfix/sasl/smtpd.conf, changed saslauthd_path from /var/run/saslauthd/mux to /var/spool/postfix/var/run/saslauthd/mux - added postfix user to group sasl - It still didn't work, meaning that Oulook prompted for login and password which were always refused. I was getting: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory --> THEN, when I commented out the saslauthd_path line in smtpd.conf, SASL suddenly started working! I'm no longer prompted for login/password. It stopped working when I uncommented this:(which you recommended). -o smtpd_client_restrictions=permit_sasl_authenticated,reject So commented it back in and it works. Maybe it is conflicting with something? FWIW I found on the net a way to find out where saslauthd is: netstat -peln | grep saslauthd # netstat -peln | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 5800975 11353/saslauthd /var/spool/postfix/var/run/saslauthd/mux unix 2 [ ACC ] STREAM LISTENING 5713075 26139/saslauthd /var/run/saslauthd/mux unix 2 [ ACC ] STREAM LISTENING 5803536 11992/saslauthd /var/spool/postfix/var/run/saslauthd/mux Don't ask me why the second line is there. That /var/run/saslauthd folder doesn't exist anymore. Must be an old thread.. OK. Now, the question is, SASL works but is TLS really encrypting the traffic when I send my login to postfix? The AUTH LOGIN method is a plain text format I understand. In the mail.info log, the POP3 connections via dovecot say TLS started but the SMTP connections do not say that. Quick background: I didn't really understand the way to use dovecot in postfix, which might have been faster. My postfix has both dovecot and cyrus support and I'm using cyrus. So my (maybe confused) understanding is that the postfix TLS setup is a totally separate one from the one being used by dovecot, instead of somehow hooking into dovecot's TLS. FWIW there is some info related to this at: http://ubuntuforums.org/archive/index.php/t-346366.html and some nice material from Hardening Linux by James Turnbull - has a section on hardening email and postfix page 373 and SMTP AUTH page 383 which is at: http://books.google.com/ In the mail log, I get sasl_method=LOGIN, sasl_username=xxxxx In Outlook account settings > Advanced, I have the "This server requires an encrypted connection (SSL)" checkboxes checked for both Incoming server (POP3) and Outgoing server (SMTP) I'm on ports 995 (POP3) and 25 (SMTP). So it ought to be encrypted.. but this is windows again. I tried to check TLS is running two ways, openssl and swaks. openssl s_client -connect host:port -starttls smtp this showed the certificate ca was not sent maybe a problem. (see log below, which says "No client certificate CA names sent" but does not fail so maybe that's not a problem? swaks -s MYDOMAIN.net -tls -a -au MYLOGIN -ap MYPASSWD --protocol ESMTPSA (ESMTPSA means smtp +tls +authentication) It says TLS started w/ cipher DHE-RSA-AES256-SHA then AUTH LOGIN and Authentication successful, so I think TLS worked maybe. But then why doesn't it say tls used in the postfix mail.info log? (see swaks log below) I am using a self-signed cert by the way, which I made like so: mkdir /etc/postfix/sasl cd /etc/postfix/sasl openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650 I am using this same /etc/postfix/sasl/smtpd.pem for cert. (See at bottom, my main.cf.) I leave you with this output from the openssl test, I'd appreciate it if you could tell me 1) is TLS working now, 2) must I add some kind of CA certificate. Thanks a million! Sincerely, Matt Below are the openssl and swaks logs. OpenSSL test: $ openssl s_client -starttls smtp -connect localhost:25 CONNECTED(00000003) depth=0 /C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxxx verify error:num=18:self signed certificate verify return:1 depth=0 /C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxxx verify return:1 --- Certificate chain 0 s:/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx i:/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx --- Server certificate -----BEGIN CERTIFICATE----- snip -----END CERTIFICATE----- subject=/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx issuer=/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx --- No client certificate CA names sent --- SSL handshake has read 1715 bytes and written 351 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: xxxxx Session-ID-ctx: Master-Key: xxxxx Key-Arg : None Start Time: 1245066243 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- 250 DSN (and here I can type into the ongoing telnet session) SWAKS log: $ swaks -s xxxxxxxx.net -tls -a -au USERNAME -ap PASSWORD --protocol ESMTPSA To: xxxxxxxxxxxx@gmail.com === Trying MYDOMAIN.net:25... === Connected to MYDOMAIN.net. <- 220 MYDOMAIN.net ESMTP Postfix (Ubuntu) -> EHLO localhost <- 250-MYDOMAIN.net <- 250-PIPELINING <- 250-SIZE 10240000 <- 250-VRFY <- 250-ETRN <- 250-STARTTLS <- 250-AUTH PLAIN LOGIN <- 250-AUTH=PLAIN LOGIN <- 250-ENHANCEDSTATUSCODES <- 250-8BITMIME <- 250 DSN -> STARTTLS <- 220 2.0.0 Ready to start TLS === TLS started w/ cipher DHE-RSA-AES256-SHA ~> EHLO localhost <~ 250-MYDOMAIN.net <~ 250-PIPELINING <~ 250-SIZE 10240000 <~ 250-VRFY <~ 250-ETRN <~ 250-AUTH PLAIN LOGIN <~ 250-AUTH=PLAIN LOGIN <~ 250-ENHANCEDSTATUSCODES <~ 250-8BITMIME <~ 250 DSN ~> AUTH LOGIN <~ 334 VXNlcm5hbWU6 ~> bWF0dHI= <~ 334 UGFzc3dvcmQ6 ~> Z3lvemE5OQ== <~ 235 2.7.0 Authentication successful ~> MAIL FROM:<mattr@localhost> <~ 250 2.1.0 Ok ~> RCPT TO:<xxxxxxxxxxxxxxxx@gmail.com> <~ 250 2.1.5 Ok ~> DATA <~ 354 End data with <CR><LF>.<CR><LF> ~> Date: Mon, 15 Jun 2009 20:56:34 +0900 ~> To: xxxxxxxxxxxx@gmail.com ~> From: mattr@localhost ~> Subject: test Mon, 15 Jun 2009 20:56:34 +0900 ~> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks ~> ~> This is a test mailing ~> ~> . <~ 250 2.0.0 Ok: queued as 3D7F78DDA ~> QUIT <~ 221 2.0.0 Bye === Connection closed with remote host. main.cf: # See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = /usr/share/doc/postfix # TLS parameters smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = telebody.net mydestination = MYDOMAIN.net, localhost, ANOTHERDOMAIN.com, ANDANOTHER.com, mail.MYDOMAIN.net mailbox_size_limit = 0 recipient_delimiter = + smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces permit_sasl_authenticated reject_unauth_destination # Added by Matt 2009-0310 header_checks = regexp:/etc/postfix/header_checks html_directory = /usr/share/doc/postfix/html smtpd_sasl_auth_enable = yes smtpd_delay_reject = no smtpd_use_tls = yes smtpd_tls_cert_file = /etc/postfix/sasl/smtpd.pem smtpd_tls_key_file = /etc/postfix/sasl/smtpd.pem broken_sasl_auth_clients = yes smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated smtpd_tls_CAfile = /etc/postfix/sasl/smtpd.pem smtp_sasl_security_options = noanonymous #smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_type = cyrus #relayhost = $mydomain relayhost = smtpd_sasl_path = smtpd |
|
| Author: | db3l [ Mon Jun 15, 2009 5:10 pm ] |
| Post subject: | Re: [SOLVED!] Postfix can't find saslauthd |
mattr wrote: So I think it is solved. But I leave my post here for anyone who has this problem in the future. Glad to hear that you're up and running. Perhaps I can shed a little light on some of the questions you encountered along the way. Quote: After reading your post, I did: (...) - in /etc/postfix/sasl/smtpd.conf, changed saslauthd_path from /var/run/saslauthd/mux to /var/spool/postfix/var/run/saslauthd/mux (...) That setting, as you found out, is superfluous, since Postfix's default will work fine as long as you set the OPTIONS field in /etc/default/saslauthd appropriately as in my first post. Remember that Postfix runs chroot'd in /var/spool/postfix. So when you included the setting, any value you put there is relative to that root. If you were going to include the setting, the right value would have been "/var/run/saslauthd/mux". Quote: It stopped working when I uncommented this:(which you recommended). -o smtpd_client_restrictions=permit_sasl_authenticated,reject So commented it back in and it works. Maybe it is conflicting with something? I'm not entirely sure if you are saying it works with or without that setting. Normally you comment something "out" not "in" - are you saying it fails with this line or without it? If it only works without this line, that does seem strange, since your sender restrictions in main.cf only let mail be relayed with SASL authentication, so if that's working it would imply your client is authenticating properly, which in turn ought to satisfy these restrictions as well. So I can't say for sure why having the setting enabled causes a failure. Unless the failures were when you were also making other changes, so perhaps you'd be able to turn this back on in your final configuration. Not having this setting does mean that you are permitting unauthenticated client connections, which may or may not be what you desire. They won't be able to relay messages but they could generate mail destined for local users, for example. If instead you're saying that it works when you leave that line uncommented, but fails otherwise, at least on my setup, it seems to work either way. It's possible that other changes you made resulted in other restrictions if you leave it off. I don't see anything obvious in the main.cf you posted, but given that you most likely want this setting anyway (to reject unauthenticated requests), not sure it's that critical. You could try checking with "postconf | grep restrictions" when you didn't have the option enabled in master.cf to see if anything jumps out at you. Quote: # netstat -peln | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 5800975 11353/saslauthd /var/spool/postfix/var/run/saslauthd/mux unix 2 [ ACC ] STREAM LISTENING 5713075 26139/saslauthd /var/run/saslauthd/mux unix 2 [ ACC ] STREAM LISTENING 5803536 11992/saslauthd /var/spool/postfix/var/run/saslauthd/mux Don't ask me why the second line is there. That /var/run/saslauthd folder doesn't exist anymore. Must be an old thread.. It looks like you have older copies of saslauthd still running. The number in front of the name (e.g., 11992 in "11992/saslauthd") is the process ID, so you might check those out. I don't know if saslauthd forks while running, so whether or not the two processes with the right path are correct. I do know that on my system, after restarting saslauthd, and even during my tests when running, I never have more than one process ID shown. It's pid will be stored in in the saslauthd.pid file in its directory (/var/spool/postfix/var/run/saslauthd in your case). I'd probably suggest either a clean reboot (if it's a test system), or kill off all the saslauthd processes you can find and then restart it cleanly. Quote: OK. Now, the question is, SASL works but is TLS really encrypting the traffic when I send my login to postfix? The AUTH LOGIN method is a plain text format I understand. In the mail.info log, the POP3 connections via dovecot say TLS started but the SMTP connections do not say that. Your final update indicated that you were able to increase the logging to identify a TLS connection, so I'll skip that. Note that if you have the smtpd_tls_security_encrypt option enabled in master.conf (my example left it commented out), then you are telling Postfix to require (as opposed to just offering) TLS on connections. For example, if I change my master.cf from my last post to include that setting, my master.cf entry becomes: Code: submission inet n - - - - smtpd And a test session to my server looks like: Code: > telnet xxxxx 587 Nothing works without STARTTLS first (which will then negotiate keys and encrypt the session). So with this configuration, the submission port (587) is guaranteed to use encryption, or in your case the default port 25. When locking things down, don't forget to ensure that you don't have Postfix accepting connections on other ports with weaker configurations. You may also note that no authentication mechanisms are shown pre-TLS. What actually happens is that an SMTP client issues the STARTTLS command and then restarts a session with a new ELHO command, at which point the available authentication options are displayed, e.g.: Code: > openssl s_client -connect xxxxx:587 -starttls smtp Quote: Quick background: I didn't really understand the way to use dovecot in postfix, which might have been faster. My postfix has both dovecot and cyrus support and I'm using cyrus. So my (maybe confused) understanding is that the postfix TLS setup is a totally separate one from the one being used by dovecot, instead of somehow hooking into dovecot's TLS. Nope, you're basically correct in terms of the configurations being distinct. TLS is security over individual connections, which each application will implement over its own connections. As such, there's really no concept of "hooking into dovecot's TLS", at least with respect to each connection. What you can do is share some of the data necessary to implement TLS. Each TLS connection is going to require certificates and keys (with each application having its own way of configuring references to those items). You can maintain those centrally for example, and could choose to use the same server certificate/key for both applications. TLS is independent of the dovecot and cyrus SASL mechanisms built into Postfix. Those deal with SASL authentication using two different libraries (and thus underlying databases), but are independent from TLS. As mentioned in my last post, the SASL authentication can occur with or without TLS - if TLS is present the SASL authentication just occurs over the secured channel. The cyrus mode lets Postfix directly access sasldb files (without needing saslauthd) for example, but Postfix still has all of its own smtpd_tls_* settings for controlling how TLS is negotiated, whether or not SASL authentication is going to be used. Quote: I tried to check TLS is running two ways, openssl and swaks These are great ways to test that your server supports TLS, but I agree that they won't necessarily indicate that some other client (like Outlook) is also using TLS, since enabling that is a client choice on a per-connection basis. In other words, your openssl test connection might work fine, but if you also permit unencrypted sessions, a client may just choose not to enable TLS. Having it required in your configuration covers that, as does some increased logging as you later determined. Quote: openssl s_client -connect host:port -starttls smtp this showed the certificate ca was not sent maybe a problem. (see log below, which says "No client certificate CA names sent" but does not fail so maybe that's not a problem? No, that shouldn't be a problem. The message is referring to "certificate CA names" and not certificates themselves. TLS supports certificate exchanges in both directions, in which case both server and client can be authenticated. The setup you're using only has a certificate transmitted to the client. The openssl message means that your server hasn't also sent a request to the client (openssl in this case) for it to provide its own certificate. Client authentication can further strengthen the security of a connection, but it requires that you generate certificates for clients and that they install them in whatever application they will be using. It's not that commonly used, particularly with public servers, and the client application has to support sending its own certificates. Quote: I am using a self-signed cert by the way, which I made like so:
mkdir /etc/postfix/sasl cd /etc/postfix/sasl openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650 I am using this same /etc/postfix/sasl/smtpd.pem for cert. (See at bottom, my main.cf.) I leave you with this output from the openssl test, I'd appreciate it if you could tell me 1) is TLS working now, 2) must I add some kind of CA certificate. 1) Yes and 2) no, but you can if you want. (My guess is for your purposes, no, unless for example you'll also be offering a secure web site or other services). The two major goals of TLS are authentication and privacy (encryption). A certificate is designed to provide authentication, as well as a starting point for negotiating the encryption key for the session. A public key within every certificate is paired with a private key (which is never released). Using a self-signed certificate essentially bypasses authentication (your Outlook client trusts that your server is who it says it is, but has no basis for that trust, so will work when connecting to any old server), but still retains encryption. Your setup really only needs the privacy of TLS since it's the SASL authentication that controls use of the service. A step up would be for you to create a CA certificate (essentially the same process but marking the certificate as a CA). Then, you can create other certificates and "sign" them with your CA certificate. You use the other certificates for servers like Postfix, and have your clients install your CA certificate in their applications so they can verify your server certificates. A further step would be to use a commercial CA (Verisign, Entrust, etc...) or public CA (such as CACert) to sign a certificate for you. You then depend on your client already having the outside CA certificate installed for verification. This is how most web site certificates work. But since you are authenticating the SMTP (or IMAP) transactions at the application level, there's not much benefit to adding complexity at the TLS level just to get further authentication. In a lighter (maybe too silly) vein, think of it this way. Let's say we have two people, Charles (your client) and Sam (your server, with its self-signed certificate). They've never met. Sam is going to the post office and is willing to drop off additional letters for anyone who asks nicely. Charles has a letter he wants dropped off, knows how to ask nicely, and is expecting to use Sam. Your current scenario of a self-signed certificate is like Charles approaching Sam, who says that yes, he's Sam. Charles takes his word for it, whispers his request nicely in Sam's ear, at which point Sam accepts the letter. Charles only has Sam's own word that he is in fact Sam, but Sam knows for sure that Charles asked nicely. Nobody else heard what Charles whispered. In the next level up, let's start over but say that someone (Matt, your self-signed CA certificate) has been introduced to Charles and Sam separately. Now Charles approaches Sam, who says that yes, he's Sam. Instead of trusting him, Charles turns to Matt and asks if he's telling the truth. Matt has previously met Sam, so he confirms Sam's story, and since Charles has met Matt, he trusts him and thus trusts Sam. So he again whispers a nice request and gives Sam his mail. The next level works very similarly, but this time, Charles has known someone else (Valerie, the Verisign CA) since high school. Sam has recently taken Valerie out for an expensive dinner, so she knows him as well. Now, when Charles approaches Sam, he can ask Valerie to vouch for Sam before handing over his letter. In each of these cases, Sam could also have asked Charles who he was (the client certificates I mentioned earlier) which in turn could have all of the same variations for how Sam could trust Charles' answer. In all cases, what Charles was whispering in Sam's ear was private, which includes, in your case, the users and passwords being used to authenticate with Postfix/Dovecot. The important aspect of the latter two cases is that the client has independent information (the CA certificate) obtained before it ever tried to connect to the server, and which it can use to verify what your server is saying. The difference between creating your own CA versus using a commercial or public certificate is largely one of how the client received the original CA certificate and how much he trusts who he received it from. The big commercial CA certificates come pre-installed in browsers, for example, which is important for public web sites from a usability perspective. In an enterprise or other closed environment, on the other hand, an internal CA can be used (and internally distributed to all clients along with client certificates) which can then fully authenticate both servers and clients. Browsers, for example, all support installing additional CA certificates as well as client certificates that can be used when authenticating an intranet for example. Another example would be how OpenVPN secures its links. But unless your mail clients are going to reject a connection to a site using a self-signed certificate (unlikely), going the CA route will probably just add complexity without much benefit. -- David |
|
| Page 1 of 1 | All times are UTC-04:00 |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|