Chris-Linfoot.net

1. DNS set up
   
2. Firewall config
   
3. Keyring file creation
   
4. Domino server configuration
   
5. Testing

1. DNS Set Up

Before you start, you will need correct forward and reverse pointing for your Domino server. domino.company.example should have a host A record in public DNS pointing to 192.168.0.1 and 192.168.0.1 should have a PTR record pointing to domino.company.example.

When an SSL certificate is issued it will be issued bearing the fully qualified host name of your server and you will need to take steps to prove to the CA that the server is yours to secure. These steps include having correct DNS pointing and may well include others such as providing details of your company registration. Some CAs will verify your claim to secure domino.company.example by correlating the domain name registration with your company name and Dun & Bradstreet reference for example.

If you can't set up correct DNS for whatever reason, give up now and address that issue first.

2. Firewall Config

SMTP TLS uses TCP port 465. In addition to the other ports you have open at the firewall, you will need to open TCP/465 inbound to and outbound from domino.company.example.

If you have one of those firewalls that interferes with SMTP (example: Pix fixup), turn that off now (not the firewall, just the fixup or equivalent). Fixup and like firewall tomfoolery will prevent the use of EHLO by any SMTP client that connects. No EHLO, no TLS.

3. Keyring File Creation

If you already have an SSL certificate for domino.company.example (for HTTPS for example), you can skip this part.

To use TLS, you will need an SSL certificate on a keyring file. This keyring file is exactly the same as one used for other web security duties such as secure web access and is obtained the same way.

Open the Server Certificate Admin database on your server (typically certsrv.nsf) or create one from the template if none exists. Click Create Keyring File.

Here, Common Name means the fully qualified host name of your Domino server. Organisation should match whatever details exist in your domain registration. State should be the two letter abbreviation for your state if in the US, otherwise your region, province or whatever. British readers take note: Country is GB for Great Britain, NOT UK!

Click " Create Key Ring".

This will create two files, keyfile.kyr and keyfile.sth in the Domino root data directory. keyfile.kyr is the key ring and keyfile.sth is the stash file which holds the keyring password, hashed.

Now click Create Certificate request.

Click the Create Certificate request button:

You will need to copy and paste the entire certificate request from this screen into either an email to your certificate authority or their web form if they have one. If you are looking for an authority to use, I still recommend Digi-Sign.

Depending on how efficient your chosen CA is you should shortly receive back a certificate to be installed on the keyring. They may also send one or more trusted roots. If they do, you will need to install those on the keyring first.

To install trusted roots, click "Install Trusted Root Certificate into Keyring":

Here, File Name is the full path to the trusted root certificate file you have been sent and which you have dropped into the local file system temporarily. Repeat this step for all trusted roots you have been sent.

Now you can install your new certificate. Click "Install Certificate Into Keyring"

Here, File Name is the full path to the certificate for domino.company.example which you have dropped into the local file system temporarily.

That's it. You're done. You now have a keyring file containing an SSL certificate valid for domino.company.example and you can go ahead and modify server settings to use it.

4. Domino Server Configuration

Edit the Server Config document for domino.company.example. On the Router/SMTP / Advanced / Commands and Extensions tab, ensure that SSL negotiated over TCP/IP port: is set to Enabled. (Housekeeping tip: disable all the extensions you don't need while you're there.)

Now edit the server document for domino.company.example.

Pay close attention now! Even if your server uses Internet Site documents, you must temporarily set "Load Internet configurations from Server\Internet Sites documents:" on the "Basics" tab to Disabled. There is no need to save the server document in this state, but only by disabling Internet Site documents will you expose this part of the server document form on the Ports/Internet Ports tab. Select the Ports/Internet Ports tab now..

Every other type of Internet site has individual settings for SSL on an Internet Site document BUT outbound mail routing via SMTP does not. This is where you tell your server what keyring to use for outbound SMTP TLS. Enter the name of your new keyring file there, then go back to the Basics tab and re-enable Internet Sites if you need to.

Now you can go back to the Ports/Internet Ports tab. You will see that the SSL settings portion of the form has now been hidden. Set Mail (SMTP Inbound) and Mail (SMTP Outbound) like this:

Save the server document.

If you are not using Internet Site documents, you're done. Otherwise open your inbound SMTP Site document and configure the security tab like so:

Make sure the correct keyring file name is there. If you plan to use authentication, you can enable the Name & Password options. Otherwise leave them off.

Now you're done.

5. Testing

Restart the router and SMTP tasks.

To verify that inbound SMTP TLS is working you can set a notes.ini variable SSL_Trace_Keyfileread=1. This will log keyfile reads to the console.

Telnet into port 25 of domino.example.com. Type EHLO whatever after the greeting. You should see something like this:

220 domino.company.example ready at Thu, 2 Mar 2006 12:14:35 +0000
ehlo whatever
250-domino.company.example Hello whatever ([10.0.100.11]), pleased to meet you
250-TLS
250-STARTTLS
250 SIZE

The exact make-up of this may vary but you should see at least 250-TLS and 250-STARTTLS.

Now enter STARTTLS. You should see something like this at the Domino console:

02/03/2006 12:14:55.77 [078C:0029-0988] ReadKeyfile> Recovering password from stash file
02/03/2006 12:14:56.07 [078C:0029-0988] ReadKeyfile> Password is password
02/03/2006 12:14:56.07 [078C:0029-0988] ReadKeyfile> Reading keyfile c:\lotus\domino\data\keyfile.kyr
02/03/2006 12:14:56.09 [078C:0029-0988] ReadKeyfile> Looking for trusted roots
02/03/2006 12:14:56.19 [078C:0029-0988] ReadKeyfile> Found trusted roots
02/03/2006 12:14:56.19 [078C:0029-0988] ReadKeyfile> Exit status = 0
02/03/2006 12:14:56.19 [078C:0029-0988] ReadKeyfile> Recovering password from stash file
02/03/2006 12:14:56.19 [078C:0029-0988] ReadKeyfile> Password is password
02/03/2006 12:14:56.19 [078C:0029-0988] ReadKeyfile> Reading keyfile c:\lotus\domino\data\keyfile.kyr
02/03/2006 12:14:56.19 [078C:0029-0988] ReadKeyfile> Looking for cert chain
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Got cert chain
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Exit status = 0
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Recovering password from stash file
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Password is password
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Reading keyfile c:\lotus\domino\data\keyfile.kyr
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Looking for private key
02/03/2006 12:14:56.23 [078C:0029-0988] ReadKeyfile> Decoding keys
02/03/2006 12:14:56.27 [078C:0029-0988] ReadKeyfile> Keys decoded
02/03/2006 12:14:56.27 [078C:0029-0988] ReadKeyfile> Exit status = 0

Things to look out for: Correct keyring file is being used. Password is found. Exit status is 0.

Testing outbound is less straightforward. You need to wait until the Domino server encounters an external host which offers TLS. When one does, your server will attempt to negotiate a secure channel and you will see a similar SSL keyfile read debug trace at the Domino console.

Remember to set notes.ini SSL_Trace_Keyfileread=0 when you have finished.

Finished. That wasn't difficult or expensive and it does offer some real security benefit where the supposed security benefits of many other common practices around Internet mail are wholly illusory.

Tags: Show-n-Tell Thursday, ShownTellThursday, SnTT

Category: SnTT
Technorati: SnTT

1. Jan-Piet Mens02/03/2006 17:22:28
Homepage: http://blog.fupps.com

Very nice, thanks. As you will know, you don't really have to have the site's certificate signed by a "real" CA; it can be signed by your own because most SMTP servers I've been confronted with, don't do root-certificate verification. In fact our internal CA signs all SSL certificates (SMTP & HTTP) and we've never yet had a complaint regarding our external mail servers

2. Chris Linfoot02/03/2006 17:32:14

I agree that many SMTP servers don't do root certificate verification though in my experience quite a few do. Also, to make this truly worthwhile, all should in my opinion. But you could go with a self cert for testing purposes.

3. Russell Eubanks03/03/2006 15:50:30

Many thanks. I was good for everything except setting up the keyring file. It's good to have step-by-step for integrating the certificate.

4. Oliver Regelmann03/03/2006 16:16:55
Homepage: http://www.n-komm.de/blog

A small addition: TLS has to be activated in the Domino configuration document (this setting only exists for inbound SMTP). Otherwise Domino at least won't list 250-TLS or 250-STARTTLS after EHLO.

5. Chris Linfoot03/03/2006 17:38:10

Good call. Fixing that now.

6. Oliver Regelmann06/03/2006 09:52:21
Homepage: http://www.n-komm.de/blog

I might be wrong, but if I understand the admin help correctly, your settings will make Domino to first try SSL on port 465 for outbound SMTP and use port 25 if it can't connect. This will appear in your logs as

The server is not responding. The server may be down or you may be experiencing network problems. Contact your system administrator if this problem persists.

on most outgoing mails.

To enable outbound TLS the outbound SMTP port status in the server document has to be set to "Negotiated SSL".
See also:
http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/24c866da7c7cd2e585256cee006b40e4?OpenDocument

7. Chris Linfoot06/03/2006 10:03:25

Yet another good call. Fixing that too. Or perhaps I should just delete this post and try again.

8. Oliver Regelmann06/03/2006 10:46:29
Homepage: http://www.n-komm.de/blog

No no, I liked it. It was the reason for me to try TLS out after all. Do you know any possibility to log TLS sessions in a manner to know e.g. how many sessions there are per month and how big the percentage of all SMTP sessions is? I tried out some MX hosts and TLS doesn't seem to be very common.

And another question: If I use a self signed certificate, what does that mean for SMTP servers that verify the root certificates? What will they do?

9. Chris Linfoot06/03/2006 11:03:08

Logging options for TLS are limited. You can use the SSL_Trace_Keyfileread notes.ini switch and that will reveal all SSL activity to you (in too much detail). Fine for SMTP only hosts, but if you have HTTPS there too forget it. You'll never figure out which SSL keyfile reads correspond to SMTP TLS and which to HTTPS.

If a remote SMTP does root certificate verification and you use a self cert, then root verification will fail. What happens next depends on the configuration of the remote SMTP. Three possible outcomes exist:

1 - it may accept the self cert anyway and continue
2 - it may issue a transient (4xx) failure. In this case, your message will requeue and try again until it times out and bounces.
3 - it may issue a permanent (5xx) failure. In this case, your message will bounce immediately.

As I use real SSL certs here, issued by a TTP with correct root certificates, I have no way of telling how prevalent each of these is.

10. Julian Robichaux09/03/2006 02:09:14
Homepage: http://www.nsftools.com

With GoDaddy SSL certificates so cheap these days, there's really no reason not to use one of those instead of a self-certificate. There's even an IBM technote to help you out:

Using Starfield Technologies or GoDaddy.com as a Trusted Root for SSL
http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21171707&ca=lsdom

11. Greg Hemphill27/03/2006 16:31:15
Homepage: http://www.swbc.com

What are the chances someone can tell me how to check the document properties of an email I have received in Domino 6.5 for use of TLS? I'm just trying to verify at the client whether is was secure or not.

12. Chris Linfoot27/03/2006 19:24:28

There's no way of telling from headers or any document property. I'm contemplating a feature request actually...

13. Pierre Kerchner26/04/2006 09:54:57
Homepage: http://kerchner.de/blog

are you sure that this is really TLS (3.1) and not SSL (v3.0) ?

some picky email clients only want to do TLS and claim that SSL is insecure

pierre

14. Chris Linfoot26/04/2006 11:37:51

I believe it is TLS though I don't know for sure. Lotus is fastidious about RFC compliance and if their MTA offers STARTTLS and TLS in response to EHLO, then I'm pretty certain they mean it.

They do get a bit confused with nomenclature in server and server configuration docs though, always talking about SSL where they probably mean TLS on SMTP ports. They also talk about "TCP authentication" when they mean plain text SMTP AUTH.

I reckon its just confusion over nomenclature in configuration documents rather than any indication that things aren't what they seem.

Which "picky email clients" are you talking about anyway?

15. Pierre Kerchner26/04/2006 14:30:44
Homepage: http://kerchner.de/blog

The Bat! professional keeps saying that Domino is only talking SSL 3.0
Which is insecure and not supported

SSL3.1 is required

Maybe have a look at the Bat yourself.

Looks like it has features are really nice

pierre

16. Norm Van Bergen16/05/2006 13:47:08
Homepage: http://www.symcor.com

Great post Chris - thanks for the hard work and subsequent updates. Are you aware of a way of getting Domino to force TLS to specific target domains (and fail/bounce if they can't negotiate an encrypted session) but not others?

Thanks,
Norm...

17. Chris Linfoot16/05/2006 13:58:11

You're not the first to ask for this but no, so far as I am aware that is not possible - yet.

TrackBack From simtation.com21/06/2006 13:41:56

Keyring file access errror for outbound mail.

Hi Chris, Nice article and made my SMTP accept SMTP Auth/TLS, Thank you. However I am not able to do it for the outgoing SMTPAuth. Getting this error "read failed with status 2" "exit status = 1028" "Keyring file access errror"

19. Chris Linfoot21/06/2006 15:34:38

Is the stash file present in the same location as the keyring file?

20. Bastian Wieczorek11/08/2006 16:40:34
Homepage: http://www.lntoolbox.com/

Hello Chris,

there exist a lotus domino ini entry (since R654 FP1):
RouterFallbackNonTLS=1
which can be used to fallback to non TLS if there is a problem with TLS on the recipient server.

regards

Bastian W.

21. Rajat Sharma24/08/2006 19:02:24
Homepage: http://Sabre.premiseshelp.com

Is there a way to receive emails for multiple domains using SSL ? Currently we use domainA.com and domainB.com for incoming smtp email, one a single server. Now we want to move to TLS SMTP for communicating with an external organization for both the domains.

How would an external server verify the identity of our server with only one keyring file (which has a single FQDN) ?

22. Chris Linfoot24/08/2006 19:37:36

You don't need to change anything. All TLS does is establish a secure channel. It has little to do with domains being used in email sender or recipient envelopes. So if your server has a FQHN in domainA and a matching SSL cert, it will quite happily receive email addressed to domainB over a TLS/SSL channel.

23. Rajat Sharma24/08/2006 21:49:42
Homepage: http://Sabre.premiseshelp.com

Thank you Chris, for such a prompt reply. I will be implementing this change tonight.

best regards

Rajat.
Next step: book my flight for Lotusphere 2007!

24. Chris Linfoot25/08/2006 08:33:51

You can afford to go to Lotusphere, then?

http://www.greyhawk68.com/greyhawk68/home.nsf/d6plinks/GREK-6SXQE2

25. Andy Coker03/01/2007 20:12:22

I'm checking to see if there is a way to enforce TLS for certain domains. The way we are configured now is negotiated so that others sending from this server can still have their mail recieved. Maybe I'm off track here, but if I enforce TLS the receiving server would need to have TLS set up to receive the mail, otherwise it doesn't go out.

26. Chris Linfoot04/01/2007 11:22:39

There's no way to enforce TLS for only some domains using a single outbound server. You could set up an additional outbound server and route email for selected domains to that, then enforce TLS. However, if you have negotiated TLS working and the inbound servers at the sites you want to use TLS with also support it, then there's no reason to assume that TLS negotiation won't succeed each time.

27. Andy Coker04/01/2007 16:08:46

Thanks for the info Chris,

My current enviornment has 14 mail servers and all have the ability to send SMTP mail. However, I have set the outbound SMTP server for the users who request TLS to a different server because I had SSL already set there. If I limit the domains that mail is allowed to send on that server wouldn't it limit anyone who was trying to send mail to other domains? Is it possible that people who use the TLS server as their home/mail server to redirect their mail to a different server? I'm at a loss as to how I could set the people homed on this server to redirect their mail to a different one so SMTP doesn't stop routing. Thanks so much for the quick response.

28. Chris Linfoot04/01/2007 16:24:05

Can't do it. My assumption was that gateway devices were not also used as homes for users. If they are then a user homed on a server with enforced TLS, attempting to send any email at all will have all his email forced to TLS at that server and of course, most will fail.

Actually the whole idea of trying to pick out selected Internet domains and route email to them differently just using a Domino infrastructure is difficult and not a well trodden path either. Better to have all Internet email routed to one or a small number of servers based on whatever network/routing topology suits you and then just negotiate TLS as and when you can.

29. Mani Senthilnathan12/01/2007 20:40:15
Homepage: http://www.osc.gov.on.ca

Hello Chris,

My SMTP server is known to our intranet as smtp.osc.gov.on.ca, and known to the internet as smtp2.osc.gov.on.ca. I am trying to setup TLS only for internet inbound e-mails, and I do not need TLS for intranet connection. I am thinking of using internet site document. will there be any issue if an intranet server has TLS enabled and trying to negotiate with my server?

Thank you

30. Chris Linfoot12/01/2007 20:56:58

I doubt it.

Clearly the cert will not match the name of the server as seen by an intranet host but most MTAs are fairly tolerant of this by default.

Any reason you need SMTP TLS inside the local domain?

31. Travis Johnson19/01/2007 20:05:46
Homepage: http://N/A

I have a question question about enforcing TLS. If you have two different companies who have already setup TLS between eachother, do both have to set their server to "enforcing" to enforce TLS? I would think that if just one server, say ServerA is configured to enforce TLS then ServerB can only send TLS encrypted messages to it. If there is a TLS negotiation problem, then mail will not be transmitted. Is this assumption correct? Or do both servers need to turn on enforced TLS between those two domains/companies?

32. Chris Linfoot19/01/2007 20:50:21
Homepage: http://chris-linfoot.net

Enforced TLS will most probably break things as the SMTP listener will be listening on port 465 and remote systems will try port 25 and fail to connect.

Both systems would need enforced TLS and then no third party system not enforcing TLS would ever be able to connect to either of them.

Also, if there is a TLS negotiation problem in negotiated TLS this is usually enough to prevent transmission.

33. Mani Senthilnathan12/02/2007 19:50:26

I have negotiated inbound TLS enabled, but according to SMTP stat, total numbe of inbound SSL is 0. does this mean the inbound TLS is not working?

SMTP.Sessions.Inbound.Accept.Queue = 0
SMTP.Sessions.Inbound.Active = 1
SMTP.Sessions.Inbound.Active.SSL = 0
SMTP.Sessions.Inbound.BytesReceived = 835,103,967
SMTP.Sessions.Inbound.BytesSent = 6,437,298
SMTP.Sessions.Inbound.Peak = 11
SMTP.Sessions.Inbound.Peak.SSL = 0
SMTP.Sessions.Inbound.Total = 12321
SMTP.Sessions.Inbound.Total.SSL = 0
SMTP.Sessions.Inbound.Total.SSL.Bad_Handshake = 0
SMTP.Sessions.Outbound.Active = 1
SMTP.Sessions.Outbound.Active.SSL = 3169
SMTP.Sessions.Outbound.BytesReceived = 2,031,690
SMTP.Sessions.Outbound.BytesSent = 714,412,546
SMTP.Sessions.Outbound.Peak = 8
SMTP.Sessions.Outbound.Peak.SSL = 3169
SMTP.Sessions.Outbound.Total = 6233
SMTP.Sessions.Outbound.Total.SSL = 3169
SMTP.Sessions.Threads.Busy = 0
SMTP.Sessions.Threads.Idle = 5
SMTP.Sessions.Threads.InThreadPool = 5
SMTP.Sessions.Threads.Peak = 8
22 statistics found

Any reason why?

34. Chris Linfoot12/02/2007 22:34:49

It may mean it isn't working, or it may just be that no remote client has connected and attempted to negotiate a secure channel. TLS, sadly, does remain a little used extension.

Try testing, per step 5 above. Test from outside your firewall to simulate what an external client sees. Is Pix fixup getting in the way?

35. M Yohey05/04/2007 20:53:12

Your document was very helpful in setting up TLS but now I need to tweak the ciphers that are allowed using the notes.ini setting SSLCipherSpec to restrict certain cipher suites. Is there a document that lists more specific information about the ciphers.... admin help did not go into great detail.

36. Chris Linfoot05/04/2007 22:18:50

I thought you tweaked the ciphers used in the SMTP Inbound Site document not notes.ini

37. M Yohey06/04/2007 13:46:01

I'll check the SMTP Inbound Site document then, thank you!

38. Susan Danielson09/05/2007 19:44:46
Homepage: http://www.oneeamerica.com

Chris,
Thanks for putting this article out. It's been very useful to me as I've attempted to get TLS setup in my environment. I'm in desperate need of some advice, however.

I've run into some issues getting TLS to work. We use Postini for SPAM and "perimeter" management... We have three Domino Servers setup for SMTP. SMTP1 (Inbound only) SMTP2 (Outbound only) and SMTP3 (re-injection host).
SMTP1 is in the DMZ. It has a hostname of mail1.oneamerica.com which is, I believe, set up properly for both internal and external DNS. I've created the Certificate and applied it, opened up 465 on the firewall, and turned TLS on in Domino. To me, everything looks right, and we should be able to receive mail via TLS... but we cannot. Postini is saying we have to apply the cert to our firewall because we're Domino. Does that seem right to you? Do you know of other Domino shops who have had to apply certs to a firewall to get TLS to work?
Outbound is another issue, since SMTP2 is an internal server, and no public DNS recognizes it's host name. I'm working on that!

A bigger question... how do other Domino shops architect SMTP servers? Internal or in the DMZ?

Thanks in advance for any comments or help. Any and all are appreciated!!
Susan

39. Chris Linfoot09/05/2007 20:28:41

If I recall correctly Postini is one of those outside-the-perimeter email solutions, like Messagelabs, yes?

If so, then you will have repointed MX for your domains to Postini and Postini will then forward to your "real" MX. Right so far?

That means you want an SSL transaction inbound from Postini?

Why?

Is it because you are worried that people may be intercepting SMTP packets in transit from Postini to you? Given that you trust Postini already, SSL will not help you to trust them more.

Also, is Postini offering a negotiated SSL channel to remote systems sending inbound email to your public MX (a Postini server)? If not, then there's little point in trying to implement SSL for the last hop - messages are being transferred in the clear as far as Postini anyway.

SSL comes into its own when email transactions come directly from one organisation's outbound server to the real MX server of the receiving organisation so I really can't see what benefit you expect to get from this.

However, to answer the question re firewall. The firewall is transparent to an inbound system where ports are open to a host in your DMZ (in this case TCP ports 25 and 465). Where ports are closed, it is opaque. You cannot implement SSL at the firewall because the firewall is not an active participant in the SMTP conversation (unless you have Pix fixup turned on - in which case turn it off).

In other words, the advice to implement the cert at the firewall is incorrect. Are they perhaps under the impression you have an SMTP appliance at the border?

As for what other shops do - there are three common modes of operation.

Here we have inbound and outbound Domino SMTP servers in the DMZ. This is perfectly secure providing you are careful with firewall config and ESMTP extensions.

Other shops often use an appliance like an Ironport at the border and have Domino inside the secure zone of the network.

Finally, services like Messagelabs and Postini are not uncommon, but I've never seen these implemented with SSL.

40. Susan Danielson10/05/2007 15:42:21
Homepage: http://www.oneamerica.com

Chris,
Thanks for your response.

Postini is a perimater management service. We do have our MX records set up as you indicated.

I agree that putting certificates on the firewall, when they have no part other than passing the SMTP traffic, is incorrect.

In order to be able to state to customers that our emil is secure, our security office has indicated we need to secure all traffic to and from postini. We've also purchased an ad-hoc secure email solution from Postini that allows our customers to go to a website to send us secure email. Evidently, this requires our connections with them to be secure as well.

So I am stuck with why my inbound TLS is not working. I suspect it has to do with the LinkController and Packet shapers we have in our path that mask addresses. I'm working with the network folks here to figure that out.

Thanks for you help!
Susan

41. Mark G20/11/2007 20:21:38

Hi Chris,

Your instructions look create. However, I am getting stuck quite early on. When I click create keyring I get an error message.
" Invalid or non-existent document".

Any help would be greatly appreciated.

42. Craig Wiseman18/12/2007 16:38:24
Homepage: http://www.wiseman.La/cpw

Pls forgive my silliness with this question.
Suppose you have three servers that are set up for SMTP:
S1.site.com, S2.site.com, & S3.site.com.
I would need three certs, one for each server. Am I correct in assuming that you have to have three different keyrings and three different SMTP site documents, one for each server?
Is there no way to get a cert for each server and store them all in one keyring? That way you can have one config that points to that keyring.
I guess I was assuming that was a function of a keyRING - you can put multple keys on the RING.

43. Chris Linfoot18/12/2007 16:53:22

You could probably use a wildcard cert, if all servers are in the same domain, though I haven't tried this.

The ring of the keyring alludes to the fact that it does not contain a single certificate anyway. It contains your local certificate plus intermediate certificates to relate it to an already trusted root.

44. Craig Wiseman18/12/2007 16:57:57
Homepage: http://www.wiseman.La/cpw

Thanks! I've always used separate keyrings and thought I'd ask. The wildcard certs .... worry me, so I haven't used them.

45. Craig Wiseman18/12/2007 21:57:30
Homepage: http://www.wiseman.La/cpw

Oh, I forgot to say, "Thanks a lot for this !!!!"
Where ARE my manners?!

46. Ralph27/02/2008 14:38:56

Chris,

I read the article ... understand it I think ... question for you:

1. Our co. wishes to use TLS outbound/ inbound ... do the others out there (can be anyone) need TLS enabled on their end ?

thanks
Ralph

47. Chris Linfoot27/02/2008 18:49:18

TLS is always mutual. It will only work for send or receive where the other end both supports it and (in the case of remote senders) attempts to negotiate a TLS channel. The worst case possibility is that you enable negotiated TLS and it is never used because no sites sending to you or receving from you support it. In all cases, where TLS is not invoked, email will continue to flow successfully, but in clear text.

48. Rob Dalzell14/05/2008 12:49:49
Homepage: http://www.bankofamerica.com

I am a TLS email encryption engagement manager at a large American bank. Whenever we implement TLS we do it in required/enfored mode. I have personally completed TLS implementations with over 200 companies over the past 3 years.
I am trying to update our documentation with regards to Lotus Domino. What we currently have is as follows:

Domino is not currently capable of performing forced TLS based on destination domain name or server name. Domino can be 100% no TLS, 100% opportunistic TLS, or 100% forced TLS for all email passing through a particular node. You may build out a separate Domino server to perform all outbound TLS for your organization and route all email destined for our domains to that server or use a different MTA for outbound transport. It is unknown at this time if Domino 8.0 is more flexible.

Do you know if this is accurate or if it can be better stated. I’d also like to get a review from IBM but I don’t have a contact there.

49. Chris Linfoot14/05/2008 13:08:13

Seems about right to me.

50. Rob Dalzell14/05/2008 14:17:11
Homepage: http://www.bankofamerica.com

Thanks for the prompt reply!!!

Unable to post a comment? Please read this for a possible explanation...