| Groups | Blog | Home |
iis smtp nntp : Configuring SSL in IIS SMTP
the IIS SMTP stack. I've verified that the SMTP stack is configured correctly and accepting messages on the port I've designated (I'm using a non-standard port). I successfully transferred a message through it before I started trying to turn on the SSL part. I'm requiring authentication and that works OK too. Using the wizard, I generated a cert request, purchased a cert from Verisign, and installed the cert. Restarted the SMTP service. When I attempted to send from a client (Agent) where I am able to specify the correct port, and specify that the server requires SSL, I get the error: Unable to negotiate an SSL connection with server xxx.xxx.xxx (error 80090308) Outlook Express yields a similar, but different, error. In the SMTP logs on the server, I see the connect attempt, but the message is not transferred. So I know it is getting through to the port, but failing to negotiate a secure channel so is refused. I'm a little confused between the Require TLS checkbox on the Authentication tab (I've got that unchecked right now) and the "Require secure channel" option in the Communication tab (sorry, if I'm remembering this slightly incorrectly; this is from memory from work today). If my intent is that the entire conversation is encrypted, but especially the authentication when used by a client that supports "SSL" (such as an iPhone), what option do I want to specify? Anything unique about the cert required to operate with SSL? Any suggestions
[quoted text, click to view]
> I've verified that the SMTP stack is configured correctly and > accepting messages on the port I've designated (I'm using a > non-standard port). I successfully transferred a message through it > before I started trying to turn on the SSL part. I'm requiring > authentication and that works OK too. OK -- although I would go back to allowing anonymous submission during a testing period (obvs. not exposing the test server any more than you need to). [quoted text, click to view] > Using the wizard, I generated a cert request, purchased a cert from > Verisign, and installed the cert. Restarted the SMTP service. Yep. [quoted text, click to view] > When I attempted to send from a client (Agent) where I am able to > specify the correct port, and specify that the server requires SSL, > I get the error: > > Unable to negotiate an SSL connection with server xxx.xxx.xxx (error > 80090308) > > Outlook Express yields a similar, but different, error. OE is a particularly bad MUA to test this setup with, unless it is your sole corporate standard. This is because OE does STARTTLS on port 25 only, assuming you mean start-to-finish encryption (SMTPS) if you run on another port. And since IIS expects a STARTTLS session, not an SMTPS session, this means having a test bed that is broken from the get-go! [quoted text, click to view] > I'm a little confused between the Require TLS checkbox on the > Authentication tab (I've got that unchecked right now) and the > "Require secure channel" option in the Communication tab (sorry, if > I'm remembering this slightly incorrectly; this is from memory from > work today). 'Require TLS' in the AUTH portion of the GUI means that at least the credentials themselves must be wrapped in a STARTTLS/STOPTLS encrypted portion of the conversation, if credentials are passed (if anonymous is off, then creds are always passed, of course). In other words, this requires encryption of the authentication stage without necessarily encrypting any other part of the SMTP convo (MAIL, RCPT, DATA). If you do any web development... this is like having an HTTPS page for username/password, but possibly passing users back to HTTP for the rest of their session. [Plenty of arguments for and against, by the way; I'm not passing judgment on it.] 'Require secure channel' is broader in that it requires a STARTTLS wrapper around both auth _and_ the following parts of the SMTP convo, including DATA. The setting's name is somewhat of a misnomer in that the secure channel cannot be built until after plain-text EHLO: this is, in encryption terms, a far cry from having the entire conversation encrypted from the very first handshake (which is what SMTPS dictates). Nonetheless, since SMTPS isn't an option here, the _most_ secure channel you are offered is a STARTTLS around as much of the convo as possible -- and this checkbox requires that broadest use of STARTTLS. From the sound of it, I'd bet you have a certificate trust issue. It is often good to first test from an MUA the server itself, since it may have more certs from the CA chain available. I know it sounds crazy, but even if you buy a commercial cert, it may not be in the default trusted CAs for the OS and/or MUA you're testing (and on that note, realize that some MUAs don't use the OS cert store, but rather use their own, which may be more or less populated than the OS'). And either don't test STARTTLS using OE, or make sure port 25 is listening. Also, you might check a bit in this thread: http://groups.google.com/group/microsoft.public.inetserver.iis.smtp_nntp= /browse_thread/thread/822f62085c3cfa85/eeaa643a3666dccf?hl=3Den&lnk=3Dst= &q=3Diis++smtps&rnum=3D21#eeaa643a3666dccf --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
I appreciate all that info, Sanford. Thanks!
I've been playing around with different combinations of things today, but not much success. I thought perhaps that the problem was the lack of the Verisign intermediate cert that is now required when using their certs, but I loaded that into the computer account's Intermediate cert store, and it made no difference (I actually think the server guys had already loaded that). The one combination of things I did get to work was having TLS on Authentication and Require Secure Channel on the Communications button both checked, and then using a Forte Agent 4.2 client with the option set to "Use TLS, and fail if not available". Stupid question: Does this rule out any problems with the cert, or does TLS not use the cert at all? I really get confused about TLS vs. SSL since TLS is SSL 3.0, isn't it? I tried using ports 465 and 443 instead of the one I'd chosen, but it didn't matter. Any client set to "use SSL" to talk to this server gave an error that it could not negotiate an SSL connection. FWIW, the capabilities it gives me to EHLO are shown below, and I verify that it expects to start TLS. Any additional advice would be great. I've been setting up mail servers for 15 years, but never struggled with this stuff before. I'm sure this is going to turn out to be a misunderstanding on my part of the difference betwee TLS/SSL as used on the server, and "Use SSL" in the terminology of the clients. The Forte Agent help so much as says to try the "Use SSL" and "Use TLS" settings until you figure out which is the one that works. EHLO 250-xxx.xx.xx.xx Hello [yy.zz.qqq.sss] 250-TURN 250-SIZE 10485760 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-TLS 250-STARTTLS 250 OK MAIL FROM:<a@b.c>
[quoted text, click to view]
> I've been playing around with different combinations of things > today, but not much success. I thought perhaps that the problem was > the lack of the Verisign intermediate cert that is now required when > using their certs... That's exactly the kind of missing CA trust I was talking about. You added it to the computer account store, but are you sure that Agent uses any MS cert store at all? To name a couple of notable third-party clients, Opera and The Bat! both have their own stores. Also make sure you are connecting using the same hostname the cert was issued for. Some clients are very sensitive to this. [quoted text, click to view] > The one combination of things I did get to work was having TLS on > Authentication and Require Secure Channel on the Communications > button both checked, and then using a Forte Agent 4.2 client with > the option set to "Use TLS, and fail if not available". Reasonable enough combo of settings: that means the client has the same restrictions as the server. [quoted text, click to view] > Stupid question: Does this rule out any problems with the cert, or > does TLS not use the cert at all? I really get confused about TLS > vs. SSL since TLS is SSL 3.0, isn't it? TLS absolutely uses the cert. TLS =3D SSL. If you are using a start-to-finish secure connection, such= as HTTPS and SMTPS, there's no reason to discriminate between the two technologies. TLS goes beyond legacy SSL expectations when STARTTLS/STOPTLS is used, however. SSL users are accustomed to a single point-to-point connection being either secure or plain. With STARTTLS/STOPTLS, the same connection can carry plain traffic, then switch to secure, then switch back to plain. It's advanced, and confusing. [quoted text, click to view] > I tried using ports 465 and 443 instead of the one I'd chosen, but > it didn't matter. Any client set to "use SSL" to talk to this server > gave an error that it could not negotiate an SSL connection. Right, because by "SSL" the client 'lmost inevitably means SMTPS, and the IIS server doesn't support SMTPS. Only a client that uses the generic term "secure", the variable term "TLS" (which could mean SMTPS or STARTTLS) or the explicit term "STARTTLS" has any chance of working. [quoted text, click to view] > Any additional advice would be great. Re: Agent, it seems to be currently working without any counterintuitive settings on either side. Re: OE, remember that you will have to be connecting on port 25, as OE only does STARTTLS on 25. Any other port and it thinks you mean implicit/full TLS, a.k.a. SMTP over SSL, a.k.a. SMTPS. [quoted text, click to view] > I've been setting up mail servers for 15 years, but never struggled > with this stuff before. I'm sure this is going to turn out to be a > misunderstanding on my part of the difference betwee TLS/SSL as used > on the server, and "Use SSL" in the terminology of the clients. The > Forte Agent help so much as says to try the "Use SSL" and "Use TLS" > settings until you figure out which is the one that works. Yes, it's not your fault on the client side. The MUA vendors obviously are trying to offer users the most streamlined experience, while on the other hand they can't safely and automatically run through a whole slew of possible security mechanisms (you risk getting disconnected, and maybe even IDS/IPS-denied, if the server doesn't like your trial-and-error methods). So the MUAs offer these partially-technical, partially-dumbed-down settings. Also, most MUA vendors know there's some kind of security they can't do (just as most MTA vendors do), so the vaguer you are, the easier it is to blame the other side. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
OK, so since I have the combination of IIS with Auth/TLS and Secure
Channel required working with the offsite client that requires TLS, then I'm certain the connectivity and certificate issues are solved. My real test for this is enabling an iPhone to send using this as an authenticated, encrypted outbound SMTP relay. The only thing I know about the iPhone configuration for outgoing email is that it has a checkbox that says "Use Secure Sockets Layer (SSL)". If this means it will enjoy a TLS conversation, then I'm done. If it means something else, then I'm toast. The iPhone's options for authentication are: none Password MD5 Challenge Response Kerberos Version 4 NTLM Kerberos Version 5 (GSSAP) My assumption here is that we are talking simple Password authentication (but over TLS). If the SSL checkbox means SSL .. that is legacy SSL .. can this be done with IIS 6 SMTP stack? Maybe I should have asked that in the first place. I have complete control over what the server is doing and the firewall allows. This MTA will be used for nothing else, so I don't really have to worry about the general case except I'd like it to work for other clients to the extend possible. I just have no idea what this particular client is expected "SSL" to be, and little access to one to play with. [Don't get me started on the wisdom of using iPhone for corporate email access. I've fought the battle based on security and functionality, and have lost. Not even AT&T support their employees using iPhones. My job now is to make it work as securely as I can.] Again, thanks for the assistance! "Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> [quoted text, click to view] wrote:
>> I've been playing around with different combinations of things >> today, but not much success. I thought perhaps that the problem was >> the lack of the Verisign intermediate cert that is now required when >> using their certs... > >That's exactly the kind of missing CA trust I was talking about. You >added it to the computer account store, but are you sure that Agent >uses any MS cert store at all? To name a couple of notable third-party >clients, Opera and The Bat! both have their own stores. > >Also make sure you are connecting using the same hostname the cert was >issued for. Some clients are very sensitive to this. > >> The one combination of things I did get to work was having TLS on >> Authentication and Require Secure Channel on the Communications >> button both checked, and then using a Forte Agent 4.2 client with >> the option set to "Use TLS, and fail if not available". > >Reasonable enough combo of settings: that means the client has the >same restrictions as the server. > >> Stupid question: Does this rule out any problems with the cert, or >> does TLS not use the cert at all? I really get confused about TLS >> vs. SSL since TLS is SSL 3.0, isn't it? > >TLS absolutely uses the cert. > >TLS = SSL. If you are using a start-to-finish secure connection, such >as HTTPS and SMTPS, there's no reason to discriminate between the two >technologies. > >TLS goes beyond legacy SSL expectations when STARTTLS/STOPTLS is used, >however. SSL users are accustomed to a single point-to-point >connection being either secure or plain. With STARTTLS/STOPTLS, the >same connection can carry plain traffic, then switch to secure, then >switch back to plain. It's advanced, and confusing. > >> I tried using ports 465 and 443 instead of the one I'd chosen, but >> it didn't matter. Any client set to "use SSL" to talk to this server >> gave an error that it could not negotiate an SSL connection. > >Right, because by "SSL" the client 'lmost inevitably means SMTPS, and >the IIS server doesn't support SMTPS. Only a client that uses the >generic term "secure", the variable term "TLS" (which could mean SMTPS >or STARTTLS) or the explicit term "STARTTLS" has any chance of >working. > >> Any additional advice would be great. > >Re: Agent, it seems to be currently working without any >counterintuitive settings on either side. > >Re: OE, remember that you will have to be connecting on port 25, as OE >only does STARTTLS on 25. Any other port and it thinks you mean >implicit/full TLS, a.k.a. SMTP over SSL, a.k.a. SMTPS. > >> I've been setting up mail servers for 15 years, but never struggled >> with this stuff before. I'm sure this is going to turn out to be a >> misunderstanding on my part of the difference betwee TLS/SSL as used >> on the server, and "Use SSL" in the terminology of the clients. The >> Forte Agent help so much as says to try the "Use SSL" and "Use TLS" >> settings until you figure out which is the one that works. > >Yes, it's not your fault on the client side. The MUA vendors obviously >are trying to offer users the most streamlined experience, while on >the other hand they can't safely and automatically run through a whole >slew of possible security mechanisms (you risk getting disconnected, >and maybe even IDS/IPS-denied, if the server doesn't like your >trial-and-error methods). So the MUAs offer these partially-technical, >partially-dumbed-down settings. Also, most MUA vendors know there's >some kind of security they can't do (just as most MTA vendors do), so >the vaguer you are, the easier it is to blame the other side. > >--Sandy > > > >------------------------------------ >Sanford Whiteman, Chief Technologist >Broadleaf Systems, a division of >Cypress Integrated Systems, Inc.
[quoted text, click to view]
> OK, so since I have the combination of IIS with Auth/TLS and Secure > Channel required working with the offsite client that requires TLS, > then I'm certain the connectivity and certificate issues are solved. I'd agree that you've made IIS SMTP as adaptive as it can be to client requirements at this point, although (see below) there are 3rd-party pieces you can add in to make it work within additional client restrictions. [quoted text, click to view] > My real test for this is enabling an iPhone to send using this as an > authenticated, encrypted outbound SMTP relay. The only thing I know > about the iPhone configuration for outgoing email is that it has a > checkbox that says "Use Secure Sockets Layer (SSL)". If this means > it will enjoy a TLS conversation, then I'm done. If it means > something else, then I'm toast. I intuit, as I mentioned before, that an app that uses the terminology "SSL" can be assumed to _not_ mean SSL v3 =3D TLS, and therefore that it= does not support STARTTLS/STOPTLS. There may be exceptions, but generally speaking, if an SMTP app says "SSL" in this day and age, they are conspicuously _not_ saying "TLS." [quoted text, click to view] > The iPhone's options for authentication are: > > none > Password > MD5 Challenge Response > Kerberos Version 4 > NTLM > Kerberos Version 5 (GSSAP) > > My assumption here is that we are talking simple Password > authentication (but over TLS). I wish I agreed with you, but I don't. Though only testing can tell you for sure, I would predict the SSL checkbox means legacy SSL, and... [quoted text, click to view] > If the SSL checkbox means SSL .. that is legacy SSL .. can this be > done with IIS 6 SMTP stack? ....no. But you can use an SSL proxy in front of IIS SMTP to do this (this is, by counterexample, at least easier than the reverse, trying to make an MTA support advanced STARTTLS/STOPTLS when it only speaks legacy SSL). [quoted text, click to view] > Maybe I should have asked that in the first place. I have complete > control over what the server is doing and the firewall allows. This > MTA will be used for nothing else, so I don't really have to worry > about the general case except I'd like it to work for other clients > to the extend possible. I just have no idea what this particular > client is expected "SSL" to be, and little access to one to play > with. Well, the biggest problem here is that you are trying to support a client that you don't own a copy of. That's the real support disaster -- forget the iPhone-as-corporate problem, it's the supporting-iPhone-without-having-one problem! --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com>
[quoted text, click to view] wrote: > 3rd-party pieces you can add in to make it work within additional client > restrictions. I may have to go that route. Pointers to add-ins would be appreciated. I take it no one here has made an iPhone work with IIS SMTP as its outgoing mailhost. :-( [quoted text, click to view] >Well, the biggest problem here is that you are trying to support a >client that you don't own a copy of. That's the real support disaster >-- forget the iPhone-as-corporate problem, it's the >supporting-iPhone-without-having-one problem! Oh, the company bought me one. I use it as a paperweight. AT&T doesn't allow transferring corporate service to an iPhone. They also don't allow you to use a corporate credit card/PO/etc. to activate the service. They require the SSN of an individual to commit to the $1500 service cost. That I am not willing to do since I already have a mobility device that does the same thing (and with push email to boot). The iPhone cannot be used to even play an MP3 file without an individual making that $1500 committment. But it does make a great
[quoted text, click to view]
> You can build an SSL reverse proxy on Apache, which would be a comfort > zone for a lot of people. ^U... my bad, ignore; I misremembered what mod_proxy could/is supposed to do, thought it had been made super-generic. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
[quoted text, click to view]
> I may have to go that route. Pointers to add-ins would be > appreciated. stunnel is the classic, SSL Proxy very similar. I've used them but honestly don't know about their scaleability. Delegate is complex and docs a bit abstruse, but will also give you what you want. You may want to try one of these three just to make sure all of our hypotheses are correct. FastStream IQ Reverse Proxy, which I do use for HTTPS, is extremely scaleable -- though its price would likely mean you'd want to get something else out of it as well. You can build an SSL reverse proxy on Apache, which would be a comfort zone for a lot of people. [quoted text, click to view] > Oh, the company bought me one. I use it as a paperweight. :))). --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
Good news (for me). It appears that the iPhone, when the checkbox for
"Use Secure Sockets Layer (SSL)" is checked and the alternate port specified, can successfully transfer a message through my IIS SMTP with the Require TLS / secure channel boxes checked. In the protocol log on the server, I observe two STARTTLS lines in the conversation. I may be done, though the testing has been very light.
[quoted text, click to view]
> Good news (for me). It appears that the iPhone, when the checkbox for > "Use Secure Sockets Layer (SSL)" is checked and the alternate port > specified, can successfully transfer a message through my IIS SMTP > with the Require TLS / secure channel boxes checked. Which means that their setting is a misnomer. Good for you! Last time 'SSL' was the right term for anything SMTP, it could only mean SMTPS (WKP TCP 465). Interesting that Apple's consumer Mail MUA (IIRC) uses the correct 'TLS' nomenclature. It's really a crapshoot out there: only techie-type clients like Mozilla & The Bat! seem to be willing to tell the truth. But their misinterpretation is to your benefit in this case, which is great. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc.
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |