[Dovecot] client certs with godaddy ssl cert
I've read the client ssl cert section in the wiki and it talks about using a self signed cert, if I am using a commercial cert, in this case godaddy, how do I implement a self signed cert for the client side and have dovecot make use of this? I know the mechanics of setting up the self signed ca, the question is more what configuration changes do I need to make in dovecot to handle both godaddy and the self signed ca functionality?
Thanks
Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
Harondel J. Sibble wrote:
I've read the client ssl cert section in the wiki and it talks about using a self signed cert, if I am using a commercial cert, in this case godaddy, how do I implement a self signed cert for the client side and have dovecot make use of this? I know the mechanics of setting up the self signed ca, the question is more what configuration changes do I need to make in dovecot to handle both godaddy and the self signed ca functionality?
if you have a commercial cert, you don't need a self signed cert. self signed certs are for people who don't want to get a cert signed by a 3d party (commercial or other). For email, you generally don't need a commercial certificate because your users know you and you know them, and because users don't connect to thousand imap servers.
On 27 Sep 2008 at 13:22, mouss wrote:
if you have a commercial cert, you don't need a self signed cert. self signed certs are for people who don't want to get a cert signed by a 3d party (commercial or other). For email, you generally don't need a commercial certificate because your users know you and you know them, and because users don't connect to thousand imap servers.
Huh? I am looking to implement client side certificates which have to be installed on the end user device before they are able to connect to my mailserver.
I already have a commercial cert on the mailserver so that's a moot point.
Secondly a client cert allows me to verify that the device connecting is
allowed, this is secondary to any login info the user may have, ie 2 factor
authentication, something you know (uid/password) and something you have
(certificate).
Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
Harondel J. Sibble wrote:
On 27 Sep 2008 at 13:22, mouss wrote:
if you have a commercial cert, you don't need a self signed cert. self signed certs are for people who don't want to get a cert signed by a 3d party (commercial or other). For email, you generally don't need a commercial certificate because your users know you and you know them, and because users don't connect to thousand imap servers.
Huh? I am looking to implement client side certificates which have to be installed on the end user device before they are able to connect to my mailserver.
sorry, I missed the "client" part.
but if you sign the client certificate, the commercial CA becomes irrelevant.
I already have a commercial cert on the mailserver so that's a moot point.
Secondly a client cert allows me to verify that the device connecting is allowed, this is secondary to any login info the user may have, ie 2 factor authentication, something you know (uid/password) and something you have (certificate).
Will you consider any certificate signed by the commercial CA as valid? if so, then you don't need to sign the certificates if you use only one CA.
what would be nice would be the support of a db of fingerprints (as in postfix) so that one can accept certificates independently of the CA, and only accept "authorized" ones.
Harondel J. Sibble wrote:
On 27 Sep 2008 at 13:22, mouss wrote:
if you have a commercial cert, you don't need a self signed cert. self signed certs are for people who don't want to get a cert signed by a 3d party (commercial or other). For email, you generally don't need a commercial certificate because your users know you and you know them, and because users don't connect to thousand imap servers.
Huh? I am looking to implement client side certificates which have to be installed on the end user device before they are able to connect to my mailserver.
Right. You need to keep track of what client certs you trust, so you really should be *at least* the immediate issuer (signer) of the client certs. The only reasons you would want your signing cert for those client certs to have a commercial issuer would be:
You want the client certs to be generally usable with those devices and servers other than your own.
The devices do not support the addition of new "root" certificates (i.e. your signing cert.)
I already have a commercial cert on the mailserver so that's a moot point.
It is also likely to be irrelevant. The signature chain of a server's cert does not influence what signing chain a client cert needs to have.
Secondly a client cert allows me to verify that the device connecting is allowed, this is secondary to any login info the user may have, ie 2 factor authentication, something you know (uid/password) and something you have (certificate).
That is only true if you are using a dependable mechanism to assure that users will actually be required to enter a password live rather than have their mail client save it
On 29 Sep 2008 at 10:43, Bill Cole wrote:
Right. You need to keep track of what client certs you trust, so you really should be *at least* the immediate issuer (signer) of the client certs. The only reasons you would want your signing cert for those client certs to have a commercial issuer would be:
That's my intent to have full control over the client certs hence the reason for going with self signed certs for the client side.
- You want the client certs to be generally usable with those devices and servers other than your own.
I do not, this is only for use with my infrastructure and will be limited to a small handfull of people.
- The devices do not support the addition of new "root" certificates (i.e. your signing cert.)
Mix of devices, but primarily windows mobile, palm, symbian and blackberry handhelds. There will also be a few laptops.
It is also likely to be irrelevant. The signature chain of a server's cert does not influence what signing chain a client cert needs to have.
Ohh.... I was wondering about that...
Okay then so as long as Dovecot is set to check client certs and the client cert presented matches the check points, CN, domain name, user email etc, it'll just work?
That is only true if you are using a dependable mechanism to assure that users will actually be required to enter a password live rather than have their mail client save it
I've already beat that one into the couple of business partners that will be making use of this. Personally I don't ever save passwords, in browsers or otherwise as a matter of course so not an issue for me.
-- Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
Harondel J. Sibble wrote:
On 29 Sep 2008 at 10:43, Bill Cole wrote:
Right. You need to keep track of what client certs you trust, so you really should be *at least* the immediate issuer (signer) of the client certs. The only reasons you would want your signing cert for those client certs to have a commercial issuer would be:
That's my intent to have full control over the client certs hence the reason for going with self signed certs for the client side.
- You want the client certs to be generally usable with those devices and servers other than your own.
I do not, this is only for use with my infrastructure and will be limited to a small handfull of people.
- The devices do not support the addition of new "root" certificates (i.e. your signing cert.)
Mix of devices, but primarily windows mobile, palm, symbian and blackberry handhelds. There will also be a few laptops.
I've heard so many conflicting stories about the X509/SSL/TLS capabilities of different mobile platforms that I don't know what to believe. I would expect that the Windows Mobile devices could use any cert you can construct, and I know that *some* Palm mailers can deal with self-signed server certs and so could *probably* deal with client certs, but even that's an iffy proposition because so many Palm devices are carrier-customized in bad ways (particularly by Verizon.) I've seen enough stupid failure when asking for client certs that I wouldn't try it with any platform where the vendor does not clearly explain how to do it.
It is also likely to be irrelevant. The signature chain of a server's cert does not influence what signing chain a client cert needs to have.
Ohh.... I was wondering about that...
Okay then so as long as Dovecot is set to check client certs and the client cert presented matches the check points, CN, domain name, user email etc, it'll just work?
Dovecot does have to trust the signing cert for the clients (i.e. it can't just be looking at some default bundle of commercial CA's) but that's not really connected to its server cert.
That is only true if you are using a dependable mechanism to assure that users will actually be required to enter a password live rather than have their mail client save it
I've already beat that one into the couple of business partners that will be making use of this. Personally I don't ever save passwords, in browsers or otherwise as a matter of course so not an issue for me.
This can't just be about education. The vast majority of users will not tolerate having to enter a worthwhile password every time they want to make a mail connection unless it is forced on them, particularly on a device with a tiny keyboard. You partners may need to be told clearly that if they cannot or will not enforce frequent password entry on end-users in some fashion, client certs are literally worthless and any effort (or money) spent to make them work initially or support them in the future is wasted.
An alternative approach that might be easier to implement on some platforms (certainly on Palm and iPhone) would be to force the device to lock on extended idle, network disconnect, or reset, requiring a password to unlock it. That enforces a "something you know" on the whole device, rather than just on mail.
On 1 Oct 2008 at 10:37, Bill Cole wrote:
I've heard so many conflicting stories about the X509/SSL/TLS capabilities of different mobile platforms that I don't know what to believe.
I've got direct experience with a bunch of the platforms, so I am not all that concerned about that problem.
I would expect that the Windows Mobile devices could use any cert you can construct,
It needs a specific format, der encoded IIRC, other than that it works fine.
and I know that *some* Palm mailers can deal with self-signed server certs and so could *probably* deal with client certs, but even that's an iffy
Back in my Palm days, the mail client I was using did support client certs, but that was a LONG time ago.
proposition because so many Palm devices are carrier-customized in bad ways (particularly by Verizon.)
My biz partner has a Telus Treo 700p or 750p. All my devices are unlocked phones so that's not a problem.
I've seen enough stupid failure when asking for client certs that I wouldn't try it with any platform where the vendor does not clearly explain how to do it.
The vendor as in the cellular telco? Bah, I pretty much ignore what they have to say. Or do you mean the OS vendor? There's plenty of info on the net about that and I've rarely had problems.
Dovecot does have to trust the signing cert for the clients (i.e. it can't just be looking at some default bundle of commercial CA's) but that's not really connected to its server cert.
Yes, I thought so and that is exactly the crux of my problem, how do I get dovecot to trust both cert chains, GoDaddy and my self signed client certs simultaneously? I can't seem to find anything on that specific issue.
This can't just be about education.
With the 2 other people I'll be dealing with, it's enough, I continually beat the security drum to them, they used to say I was just too paranoid, now when I say, events have shown I wasn't paranoid enough, they nod sagely :-) Every now and then I have to hit them with a clue stick, but they've come a long way.
The vast majority of users will not tolerate having to enter a worthwhile password every time they want to make a mail connection unless it is forced on them, particularly on a device with a tiny keyboard.
Woah, lets make the disctinction between technically inclided people who understand the risks and regular users. The 2 folks in question are of the former variety. I am well aquainted with the latter variety amongst my clients. They'd rather shoot themselves in the foot so they can have ease of use, I am quite familiar with dealing with them
You partners may need to be told clearly that if they cannot or will not enforce frequent password entry on end-users in some fashion, client certs are literally worthless and any effort (or money) spent to make them work initially or support them in the future is wasted.
At this point that's a secondary issue, I just want to get it working for MY use, once we get our colo equipment updated, then I can implement it for them, knowing full well that they don't view security as seriously as I do, hence the reason I'll probably always have my own gear under my control.
An alternative approach that might be easier to implement on some platforms (certainly on Palm and iPhone) would be to force the device to lock on
Couldn't care less about the iPhone at this point since it doesn't offer much of the business functionality I expect, maybe in 3-6 months, who know.
extended idle, network disconnect, or reset, requiring a password to unlock it. That enforces a "something you know" on the whole device, rather than just on mail.
Makes sense, I already do that with devices under my control as a matter of course.
-- Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
On Oct 2, 2008, at 6:59 AM, Harondel J. Sibble wrote:
Dovecot does have to trust the signing cert for the clients (i.e.
it can't just be looking at some default bundle of commercial CA's) but
that's not really connected to its server cert.Yes, I thought so and that is exactly the crux of my problem, how do
I get dovecot to trust both cert chains, GoDaddy and my self signed client
certs simultaneously? I can't seem to find anything on that specific issue.
I can't really answer this question, except to say that Dovecot uses
the standard OpenSSL functions to set up all certificates. So if you
can find an answer to any server using OpenSSL it's probably
applicable to Dovecot as well.
I'd guess you just put all the certs to the same file.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Oct 03, 2008 at 07:18:46PM +0300, Timo Sirainen wrote:
On Oct 2, 2008, at 6:59 AM, Harondel J. Sibble wrote:
Dovecot does have to trust the signing cert for the clients (i.e. it can't just be looking at some default bundle of commercial CA's) but that's not really connected to its server cert.
Yes, I thought so and that is exactly the crux of my problem, how do I get dovecot to trust both cert chains, GoDaddy and my self signed client certs simultaneously? I can't seem to find anything on that specific issue.
[...]
I'd guess you just put all the certs to the same file.
Yes, that's how it is supposed to work. In whatever file you keep your root certificates, you just concatenate them all (and the CRLs, the Certificate Revocation Lists). The Dovecot Wiki confirms that [1]
[1] http://wiki.dovecot.org/SSL/DovecotConfiguration#head-c61be71adc5d146a3acea0...
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFI5lduBcgs9XrR2kYRAg0JAJ0Tqz9ZjSpLA8xsbSDecmbBEEuH4wCeKUaV yqhu+5X3Sb+OA0jvTTRHlYk= =nX1o -----END PGP SIGNATURE-----
On Saturday 27 September 2008 03:43:19 Harondel J. Sibble wrote:
I've read the client ssl cert section in the wiki and it talks about using a self signed cert, if I am using a commercial cert, in this case godaddy, how do I implement a self signed cert for the client side and have dovecot make use of this? I know the mechanics of setting up the self signed ca, the question is more what configuration changes do I need to make in dovecot to handle both godaddy and the self signed ca functionality?
If I understand you correctly, you're using the godaddy certificate as the server certificate only. This is fine, AFAIK the server certificate can be completely independent from any client certificate.
What is important: you can not self-sign each client certificate, but you need a CA with a self-signed root instead. I think you understand that already, just noting that for completeness.
Then you simply configure Dovecot as described in http://wiki.dovecot.org/SSL/DovecotConfiguration
In short: Put your godaddy SSl certificate, and then the complete hierachy of godaddy CA certificates (I don't know how many levels they have) in (e.g.) /etc/ssl/dovecot.pem, and set ssl_cert_file=/etc/ssl/dovecot.pem. Don't forget to set the path to your private key or add it to the beginning of your cert file. This handles SSL/TLS for the server.
Then create the CA root certificate, and any sub-CA certificates if you want to implement a multi-level CA. For each hierarchy level generate a CRL (Certificate Revocation List). Then, from the most specific sub-CA down to the root, concatenate each CA cert and the corresponding CRL to one file, and set this file as ssl_ca_file. The order is important, and needs to be (if existing):
- Issuing CA cert
- issuing CA crl
- Intermediate CA cert
- intermediate CA crl
- Root CA cert
- Root CA crl Then configure client cert verification as described in the last section of above mentioned wiki page.
To sum it up: ssl_cert_file is responsible for server side TLS/SSL and needs to contain the complete verification path for the server certificate. It has no influence on client certs. ssl_ca_file is used for client cert verification only, and does not need to cover the server certificate.
So you can use commercial server cert and the self-managed client certs. You might want to consider though: your clients need to import the client cert you issue, and your root CA certificate as trusted cert. If *all your SSL/TLS clients* also get a client cert, you can also issue the server cert yourself, a commercial cert provides no extra value in that case.
Thanks
Regards Rainer Frey
Software Developer
Inxmail GmbH rainer.frey@inxmail.de, www.inxmail.de
Handelsregister Freiburg, HRB 5870 Ust.-ID: DE198371679 Geschäftsleitung: Martin Bucher, Peter Ziras
Thanks, your detailed instructions were EXACTLY what I was looking for, I'll try them out and report back in a few days with the results.
On 29 Sep 2008 at 8:40, Rainer Frey (Inxmail GmbH) wrote:
Then you simply configure Dovecot as described in http://wiki.dovecot.org/SSL/DovecotConfiguration
In short: Put your godaddy SSl certificate, and then the complete hierachy of godaddy CA certificates (I don't know how many levels they have) in (e.g.) /etc/ssl/dovecot.pem, and set ssl_cert_file=/etc/ssl/dovecot.pem. Don't forget to set the path to your private key or add it to the beginning of your cert file. This handles SSL/TLS for the server.
-- Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
On 29 Sep 2008 at 8:40, Rainer Frey (Inxmail GmbH) wrote:
What is important: you can not self-sign each client certificate, but you need a CA with a self-signed root instead. I think you understand that already, just noting that for completeness.
Then you simply configure Dovecot as described in http://wiki.dovecot.org/SSL/DovecotConfiguration
Followed those directions, enabled the client side certificate checking, but no go.
Then configure client cert verification as described in the last section of above mentioned wiki page. ssl_ca_file is used for client cert verification only, and does not need to cover the server certificate.
Done, I have the following enabled.
auth default { # Space separated list of wanted authentication mechanisms: # plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi mechanisms = plain ssl_require_client_cert = yes
ssl_ca_file = /etc/pki/dovecot/certs/dovecot-clientcerts ssl_verify_client_cert = yes verbose_ssl = yes ssl_require_client_cert = yes
Logs don't show anything of any interest, on the client side (windows mobile 5 phone running Web IS's Flexmail4.
When I asked their tech support about using a client cert, I got this
Greetings and thank you for contacting us.
It should be using the certs which the PDA has installed. Is the cert
installed (in the device settings > System > Certificates
We appreciate having the opportunity to help and service you. Please let
us know if there is anything more we can do.I've verified that my root ca is installed on the pda and the personal cert is also installed.
The following is all I see on the connection attempt from the pda
Oct 8 01:00:55 myserver dovecot: Dovecot v1.0.7 starting up Oct 8 01:01:51 myserver dovecot: imap-login: Disconnected: method=PLAIN, rip=10.12.13.14, lip=10.12.13.14, TLS
At this point the client device is stuck asking to confirm account credentials
-- Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
On 8 Oct 2008 at 1:05, Harondel J. Sibble wrote:
auth default { # Space separated list of wanted authentication mechanisms: # plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi mechanisms = plain ssl_require_client_cert = yes
ssl_ca_file = /etc/pki/dovecot/certs/dovecot-clientcerts ssl_verify_client_cert = yes verbose_ssl = yes ssl_require_client_cert = yes
The following is all I see on the connection attempt from the pda
Oct 8 01:00:55 myserver dovecot: Dovecot v1.0.7 starting up Oct 8 01:01:51 myserver dovecot: imap-login: Disconnected: method=PLAIN, rip=10.12.13.14, lip=10.12.13.14, TLS
The client side logs show the following at this point
2239561866 - 2008.10.9 16:11:54 R * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN- REFERRALS AUTH=PLAIN 2239561866 - 2008.10.9 16:11:54 R 0 OK Capability completed. 2239561866 - 2008.10.9 16:11:54 S 1 LOGIN ******** ******** 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0xE 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0x68 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0x68 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0x65 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0x66 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0x67 2239561866 - 2008.10.9 16:11:54 IMAP4 ServerConnection SSL status: 0xF 2239561866 - 2008.10.9 16:11:54 R 1 NO Client didn't present valid SSL certificate 2239561866 - 2008.10.9 16:11:54 *** Non Critical Error: 0x80C40001 2239561866 - 2008.10.9 16:12:50 *** Critical Error: 0x80C40001 2239561866 - 2008.10.9 16:12:50 Connection failed - stopping all connections 2239561866 - 2008.10.9 16:12:50 Connection's SyncExecute finished 3325771946 - 2008.10.9 16:12:51 Stopping synchronization... 3325771946 - 2008.10.9 16:12:51 Forcing disconnection... 3325771946 - 2008.10.9 16:12:51 Synchronization stopped 2755981250 - 2008.10.9 16:12:51 Stopping existing connections (1 total) 2755981250 - 2008.10.9 16:12:51 Deleting connection...
-- Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
On Thu, 2008-10-09 at 10:14 -0700, Harondel J. Sibble wrote:
Oct 8 01:00:55 myserver dovecot: Dovecot v1.0.7 starting up
v1.1 logs more with verbose_ssl=yes.
2239561866 - 2008.10.9 16:11:54 R 1 NO Client didn't present valid SSL certificate
My guess would be that your client just doesn't support sending SSL client certificates. Or perhaps you'd need to configure it to do it somehow.
On 9 Oct 2008 at 20:33, Timo Sirainen wrote:
v1.1 logs more with verbose_ssl=yes.
1.0.7 doesn't log anything other than the initial connection :-( Guess it's time to upgrade
2239561866 - 2008.10.9 16:11:54 R 1 NO Client didn't present valid SSL certificate
Note, this was the log from the client side, not the server side.
My guess would be that your client just doesn't support sending SSL client certificates. Or perhaps you'd need to configure it to do it somehow.
According to the client developer, it will automatically send the personal certificate, there is only a single one installed on the pda.
Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
On 9 Oct 2008 at 20:33, Timo Sirainen wrote:
My guess would be that your client just doesn't support sending SSL client certificates. Or perhaps you'd need to configure it to do it somehow.
Well contrary to what WebIS tech support says, that looks to be the case as the same client cert imported into Thunderbird works perfectly.
-- Harondel J. Sibble Sibble Computer Consulting Creating solutions for the small business and home computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
On 29 Sep 2008 at 8:40, Rainer Frey (Inxmail GmbH) wrote:
What is important: you can not self-sign each client certificate, but you need a CA with a self-signed root instead. I think you understand that already, just noting that for completeness. Then you simply configure Dovecot as described in http://wiki.dovecot.org/SSL/DovecotConfiguration
To sum it up: ssl_cert_file is responsible for server side TLS/SSL and needs to contain the complete verification path for the server certificate. It has no influence on client certs. ssl_ca_file is used for client cert verification only, and does not need to cover the server certificate.
Okay, got this mostly working, currently testing with a Nokia e61i smartphone and having a problem which I'm not quote clear on where it lies, phone issue, postfix issue or dovecot sasl issue
Here's the problem, I can successfully authenticate to dovecot via imap using client certs, however when I attempt to send an email, that is giving me errors as follows
Oct 11 23:09:40 server postfix/smtpd[25720]: xsasl_dovecot_handle_reply: auth reply: FAIL?1?reason=Client didn't present valid SSL certificate Oct 11 23:09:40 server postfix/smtpd[25720]: warning: unknown[192.xxx.yyy.zzz]: SASL LOGIN authentication failed: Client didn't present valid SSL certificate Oct 11 23:09:40 server postfix/smtpd[25720]: > unknown[192.xxx.yyy.zzz]: 535 5.7.0 Error: authentication failed: Client didn't present valid SSL certificate
On the phone, there is only the self signed personal cert used to authenticate for imap. Postfix is set to authenticate using the same self signed CA, server cert and server key.
Any ideas on what I should look at next?
I've already wiped all the certs from both the server and the phone and recreated a new CA, but same problem occurs.
Kinda out of ideas, any suggestions?
Harondel J. Sibble Sibble Computer Consulting Creating Solutions for the small and medium business computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
Note, the problem below also occurs with Thunderbird so it's something server side, but the "what exactly" has me scractching my head...
On 11 Oct 2008 at 23:43, Harondel J. Sibble wrote:
On 29 Sep 2008 at 8:40, Rainer Frey (Inxmail GmbH) wrote:
What is important: you can not self-sign each client certificate, but you need a CA with a self-signed root instead. I think you understand that already, just noting that for completeness. Then you simply configure Dovecot as described in http://wiki.dovecot.org/SSL/DovecotConfiguration
To sum it up: ssl_cert_file is responsible for server side TLS/SSL and needs to contain the complete verification path for the server certificate. It has no influence on client certs. ssl_ca_file is used for client cert verification only, and does not need to cover the server certificate.
Okay, got this mostly working, currently testing with a Nokia e61i smartphone and having a problem which I'm not quote clear on where it lies, phone issue, postfix issue or dovecot sasl issue
Here's the problem, I can successfully authenticate to dovecot via imap using client certs, however when I attempt to send an email, that is giving me errors as follows
Oct 11 23:09:40 server postfix/smtpd[25720]: xsasl_dovecot_handle_reply: auth reply: FAIL?1?reason=Client didn't present valid SSL certificate Oct 11 23:09:40 server postfix/smtpd[25720]: warning: unknown[192.xxx.yyy.zzz]: SASL LOGIN authentication failed: Client didn't present valid SSL certificate Oct 11 23:09:40 server postfix/smtpd[25720]: > unknown[192.xxx.yyy.zzz]: 535 5.7.0 Error: authentication failed: Client didn't present valid SSL certificate
On the phone, there is only the self signed personal cert used to authenticate for imap. Postfix is set to authenticate using the same self signed CA, server cert and server key.
Any ideas on what I should look at next?
I've already wiped all the certs from both the server and the phone and recreated a new CA, but same problem occurs.
Kinda out of ideas, any suggestions?
Harondel J. Sibble Sibble Computer Consulting Creating Solutions for the small and medium business computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
-- Harondel J. Sibble Sibble Computer Consulting Creating Solutions for the small and medium business computer user. help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
participants (6)
-
Bill Cole
-
Harondel J. Sibble
-
mouss
-
Rainer Frey (Inxmail GmbH)
-
Timo Sirainen
-
tomas＠tuxteam.de