Well, technically this is for any Linux VM appliance you download, not just my reverse proxy....

Anyway, every Linux host should have it's own unique host SSH key to ensure security and authenticity of the server you are connecting to. When you create a server from an OVF that doesn't happen automatically. In fact you get the SSH host key that is on the OVA at time of creation (in this case mine).....potentially opening you up to man in the middle attacks (potentially.....although unlikely).

Here's how to do it......Log in into the Proxy server as root (either via VMware console or SSH into the host using Putty) and issue the following commands:

rm -rf /etc/ssh/ssh_host_*
ssh-keygen -A

service ssh restart

Here's the expected output from the above commands....

Image:If you are using my Reverse Proxy, please change the SSH host key

Once you do this, try logging in again via SSH (again I use Putty) and you should see a warning about a potential security breach and that this could be a bad thing (see below), it's not as we meant to create a new key, so click Yes;

Image:If you are using my Reverse Proxy, please change the SSH host key
Darren Duke   |   January 14 2015 07:55:31 AM   |    proxy  linux    |   Comments [0]

UPDATE 12/17/2014 - Based on Mike's comment below it does indeed look like option 2 is supported!! So have at it, proxy away people....

Over that past few weeks I've been banging my head against the wall trying to figure out why a Traveler server that has been relocated behind a proxy would not work (it was a standalone server that was working fine before it was moved behind the proxy). Everything seemed fine, except one couldn't get to the Traveler log on page and/or add devices to the servers. Existing users worked flawlessly. Needless to say this was extremely aggravating. I'd install another, new Traveler server and put it behind the same proxy and it would work fine. WTF?

So after much digging and testing (I've create more Traveler servers in the last week than I have in the rest of my career), I think I have finally managed to work out what the issue is. I would say this is definitely a bug with Traveler, but given the issues I've had lately with PMR's I'm in no mood to play that game Russian Roulette so I decided to  figured out a fix on my own (probably and utterly unsupported but it works for me - oh, it is supported!!!).

So first, let's outline the problem/bug I found in Traveler.....

If your Traveler server Domino common name, lets say Traveler/Blah (so traveler) is the same as the hostname in the proxy URL, lets say traveler.blah.com (so traveler) then Traveler throws a wobbler. Do not pass go, do not collect $200 if you will. You will be unable to get to the Traveler web page on the device or any browser for that matter.

Now, use any other Domino server name and as long as it's not the hostname part of  URL you use on the proxy then you are fine. This is what I was inadvertently doing when I was creating new Traveler servers to test on. Doh.

So a Domino server name of LNT1/Blah and a proxy URL of traveler.blah.com.....fine! No issues, proxy works fine. "Argh!" I hear you say, "Darren, I have a Traveler server called Traveler/Blah and also use the URL traveler.blah.com to get to it....so I can't proxy it then?". Well yes......

You have two options.....

1 - Install Domino with IHS (on Windows of course) and use IHS. I don't think IHS will have this issue.

2 - (and this is the part that is probably unsupported) I was able to build a new Domino server (exact same Domino and Traveler versions as the one you want to proxy) using the Domino server name LNT1/BLAH and copied over the LotusTraveler.nsf and traveler folders out of the existing servers data folder to the new one. I then configured the proxy to use traveler.blah.com and low and behold, it works!

I've been running on the new server for a few days and so far neither iOS users nor Android users have reported any issues so, fingers crossed, this may well work. Who knew?

Here's the new flow:

Internet -> Proxy using host name traveler.blah.com -> Domino Traveler server called LNT1/Blah with a host name of lnt1.blah.com
Darren Duke   |   December 16 2014 07:10:46 AM   |    domino  traveler    |   Comments [1]

December 12 2014 Friday

How to disable SSLv3 in Domino

In my POODLE TLS post from a few days back, there was a comment asking how to fully disabling SSLv3 in Domino. You'll notice in the comments I mention that there is a way but at the time it was under NDA. Well, apparently not anymore....

Now, fair warning this may not yet be supported by IBM so if you choose to do this, you do it at your own risk (while under NDA on this, it was stated that is unsupported so YMMV).

According to this post on the Domino wiki, you can use this server notes.ini setting to fully disable SSLv3 but still keep TLS working.:


If you need this, test it before you put it into production. I have not yet done this, but everyone I know that has has had no issues so far. Again YMMV.

Darren Duke   |   December 12 2014 07:39:06 AM   |    domino  tls  ssl  poodle    |   Comments [4]

Firefox, started 27, ended 34

Chrome started 32, ended 39

IE....11 and 11

IBM finally realized the 2015 plan was imploding. Except they "realized" this in 2014, so the immense damage of the plan has already been done. Oh, and I doubt they will stop the culling.

Talking of IBM....support. Oh, how I used to use thee as a unique selling point. Now? I routinely have 14+ day periods when the assignee of the PMR doesn't respond to multiple emails. At first I thought this was just me....it isn't.

POODLE! The *secure* internet broke. Now, anyone who watches 24 will know that Chloe O'Brian could get by any encryption scheme with little more than an abacus and calculator, but low-and-behold, now so can the entire world.

Speaking of IBM, they fixed (or enhanced?) Domino!! The finally implemented TLS albeit giving us the 1999 version (TLS1.0). Way to phone it in IBM. Still IBM did show that then can actually achieve impressive feats in a relatively small period of time. I'm sure the people who achieved this are soon to be moved to positions where they can do less good.

We were told Quickr was getting Office 2013 and Domino 9 support. I'm really beginning to doubt this. Vendors seemingly live to tell customer one thing, do another, and never inform them of the (not in the customers best interest) switch. It's shameful at times.

I can still count on the fingers of no hands how many CCM implementations I've seen.

This year there were 96 IBM ICS Champions. Up from 76 this time last year. I'm still batting a 1000 for non-selection, and I'm quite proud of that. The selection process is about as transparent as IBM sales figures. There does seem to be far fewer "WTF" moments when reading the list this year, so kudos to the selection committee for putting forth less politically motivated selections.

I wrote a (now infamous) blog post about Mail.Next. There was a lot of consternation from the "powers-that-be" inside of IBM about being called a "vindictive arsehole" and much less about the point of the post. I did say IBM fixed TLS right? Oh, and I was threatened with revocation of my Champion status (see above).....you can't make this shit up.

Speaking of Mail.Next, it got a name....IBM Verse! Get it? Me neither. Based on the a fore mentioned blog post, it has been said I'm ad-Verse.  

In an effort to market Mail.Next, or maybe create something "viral" many IBMers blacked out their eyes on their social media avatars. To me it just looked like they mistakenly used their Adult Friend Finder picture by accident. Still, you can get plenty of viral stuff from Adult Friend Finder so I can see the allure.

Connect, I don't even recall going. Either that's a bad sign for me or the conference. Or both.  

Speaking of not-Lotusphere, in order to fix all the shortcomings with Connect IBM did what IBM do in moments of crisis, they renamed it. To "ConnectED". Get it? Yeah, neither did I. The only way to Google this for the longest time was to Google "Connect 2014". Given the extreme lack of information even this close to the event, one can assume that the next rename will the "Dis-ConnectED". In reality I would be shocked if ConnectED 2015 lasted to ConnectED 2016, both in name and in conference location.

Lenovo purchased IBM's Intel Server division. Just after IBM pushed hard into the cloud and bough Softlayer. Luckily for IBM neither of those things require lots and lots of servers.

Speaking of cloud, the race to the bottom continues....cheaper storage wars are ongoing between Microsoft, Amazon and Google. Soon they may well be paying us to used their stuff!

Apple released the iPhone 6 Plus. Most likely as an answer to cries for a bigger iPhone. I would suspect that they are the most returned device that Apple has had, but that just makes Apple right, so they'll quite happily eat the cost.

Oracle continue to be the most vilified IT vendor in the galaxy. Not due to how many servers Oracle requires, but due to *still* incorporating the Ask.com toolbar and home page in the Java desktop installs.

I'm kind of starting to miss This Week In Lotus. That only took a few years! There has been a lot of fodder that we could have munched on lately, so maybe that is all it is.

Technologies that made 2014 included ASUS 28" LED monitors, ACS smart cards and Veeam 8.

Technologies I thought would make 2014....Hawthorn.
Darren Duke   |   December 10 2014 03:13:19 PM   |    misc    |   Comments [7]

After a brief chat in the Lotus Notes Skype chat with Jim Casle, Declan Lynch, Steve Pridemore and Frederick Norling it has become apparent that Domino maybe susceptible to the newly discovered POODLE TLS issue (POODLE 2.0 if you will). You can read about the new issues here and here.

Go scan your servers at SSL Labs.

Anyway, provided you are using 9.0.1 FP IF1 (the TLS fix that IBM provided a while back) the apparent Domino fix is to disable AES and 3DES ciphers and run with only RC4:

Image:POODLE TLS - The POODLE Strikes Back - change your settings now....

With those changes you go from an "F" to a "B" on SSL Labs. Here is the server with AES and/or 3DES enabled:

Image:POODLE TLS - The POODLE Strikes Back - change your settings now....

Here is a Domino server with just RC4 enabled:

Image:POODLE TLS - The POODLE Strikes Back - change your settings now....

Oh, and F5's are also at risk.....

If you're on anything less than 9 then you don't get TLS so you're not affected by this.....oh, the irony. Still it would be very beneficial to IBM's public perception to get TLS 1.2 and better ciphers into Domino ASAP. Fixing this stuff once a decade is not cutting it. As you can see above RC4 is not to hot these days.

As Adam Langley puts it:

This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken

So, IBM, the ball is in your court again.......

I will be updating my free proxy soon, but that is not affected by this issue, it still gets a "B".
Darren Duke   |   December 9 2014 09:45:25 AM   |    domino  poodle  ssl    |   Comments [10]

As you read elsewhere IBM have finally addressed POODLE and TLS 1.0 are now available for for these releases on all platforms, 9.0.1 FP2, 9.0, 8.5.3 FP6, 8.5.2 FP4 and 8.5.1 FP5.

Now just implementing these fixes may not completely protect you, (thinking BEAST attack here) unless you also disable both AES ciphers in Domino. Basically these are the two ciphers you want enabled:

Image:The Domino fixes for POODLE and TLS, you may not be done yet

It's worth pointing out that with the TLS1.0 fix IBM also addressed a long time pet peeve of mine, low quality ciphers:

Removed support:
  • SSLv2
  • SSL renegotiation has been disabled
  • All weak (<128 bits) cipher suites have been disabled

A good move but you still should really disable 128bit AES ciphers too. Indeed if you have 40 or 56 bit ciphers enabled then the Domino console throws this out:

Image:The Domino fixes for POODLE and TLS, you may not be done yet

If you *do* need to enable these low quality ones then you are doing something really, really wrong.

Disable the AES ones and you may just end up with a "B" grade at https://www.ssllabs.com/ssltest/index.html (the server below was also upgraded to SHA2)

Image:The Domino fixes for POODLE and TLS, you may not be done yet

If you want an "A" use my proxy server as Apache does support TLS1.2.

Now, IBM, you have brought us into 1999 with TLS 1.0, when do we get to the heady heights of 2008 and TLS 1.2? All kidding aside IBM have shown here that they can *still* do amazingly good work in a pretty short period of time. Once the SHTF it took less than 90 days for this to be addressed. Hopefully this is the shape of things to come and this sense of urgency for security will remain and not be left on the shelf until the next end-of-the-world-security-failure scenario.

I won't hold my breath for TLS 1.2 support, but I will cross my fingers.
Darren Duke   |   November 4 2014 04:49:27 PM   |    domino  tls    |   Comments [4]

I got this question from an STS customer:

My question ... is there something I can run from the server console to make sure everyone is set up for DAOS or it is working for all mail accounts?

Well, yes there is. Using a old Domino feature called Indirect Files, copy and paste and Excel. Let me show you how......

If you're on Domino 9 make sure to add the following to your server notes.ini, This will prevent compact from failing by preventing the Router from delivering mail to a compacting NSF (oh, how I wish we had this back in 8.5!!!):


If you are not on 9, you have to do it the hard way.....either the server needs to be down, you can quit the router or you can try and try again until you get the files compacted. Pick your poison, but I'd suggest the last option until you only have a handful of errant NSF's to do.

Either way, this is how I'd tackle this issue.

1) Go to the Files tab in Domino Administrator, mail folder and sort by the DAOS State tab (in the example below I only have two NSF's, in reality I'd do these manually, but if I had a few more I'd use the process I'm outlining here):

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

2) You are interested in any mail file with a status of anything other than Read/Write. So select all those mail files matching this criteria, go to the Edit menu and select Copy :

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

3) Open Excel (or your preferred spreadsheet app.....Symphony anyone? Bueller? ) and paste in the contents, you should end up with this:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

4) We're only really interested in the Physical Path column, you can delete everything else. In a new column enter this formula (in my example I've deleted all columns except Physical Path and moved it to the A column):


Copy that cell (in my case B1) to the rest of the rows and you should end up with something like this (also remove the title row):

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

5) Now select the column with the mail file names as relative to Domino  (not the file names, so in my case column B). Once selected "copy" to the clipboard:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

6) Now it's time to pay attention.... create a new blank workbook and paste the column using the Paste Special option:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

7) Select Paste Values:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

8) Voila, you now have a new workbook with just relative file names of mail files that are not DAOS'd. Save this new file as MS-DOS (*.txt) but use the suffix .IND for the file:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

9) Get this file on your Domino server. In my case it's on the D: drive called FiletoDAOS.IND. Once there run the following command from the Domino console:

load compact -c -i -ZU -v -n -daos on D:\FileToDAOS.IND

What this does is use an Indirect file (our .IND file) as the source of files to compact....if successful you should see the results on the Domino console:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

10) If your using Domino 9 and have that notes.ini setting chances are you will get the majority compacted....if your using anything less than R9 you may have to repeat these steps several times (each time getting less and less files to be DAOS'd).

There you go. You will now slowly whittle away at the non-DAOS'd mail files on your server. Sure beats typing on the console....especially if you have more than a few mail files to do.

11) To see if you still have any left to do, look at the mail folder in Domino Admin again (remember to F9). In my case all were completed.....:

Image:Back to basics - how to DAOS enable (missed?) non-DAOS’d Domino mail files the easy way

If yours are not, go back to step 1 and whittle away again......

Darren Duke   |   November 3 2014 05:00:47 PM   |    domino  daos    |   Comments [1]

I got an email from a customer the other day about mitigating POODLE with IBM's Lotus Protector for Mail Security (LPMS). There is a technote for this, 1687838. At the top there is an interesting warning:

IMPORTANT: disabling SSLv3 for XMail may cause severe incompatibility problems with other MTAs that do not support TLS 1.x

I was asked if this was an issue. My response:

It depends on who you are STARTTLS emailing to....

This only affects domains that you have set as requiring TLS between your server and theirs. So I'd check with them before you do it

Now, in reality I'd most likely leave SSLv3 enabled in my SMTP environment (I'm not talking about clients connecting here like Outlook, Thunderbird, just edge SMTP relay servers). My rationale (to date) here is laid out below:

Scenario 1 : Both SMTP servers can do TLS1.0+
1.        I send an email to blah.com
2.        My server and the blah.com are both enabled for STARTTLS
3.        The negotiate TLS1.0, the delivery transaction is encrypted between the servers and email flows

Scenario 2 : One server can (but is not mandated to) do STARTTLS, the other can't
1.        I send an email to blah.com
2.        My server sees that blah.com cannot do STARTTLS
3.        The email is sent in plain text and the email flows

Scenario 3 : Both servers can do STARTTLS, but one will only do TLS1.0+ and the other will do SSLv3.
1.        I send an email to blah.com
2.        My server and the blah.com are both enabled for STARTTLS
3.        The servers cannot negotiate a protocol, so no encryption takes place
4.        The email is sent in plain text and the email flows

Scenario 3 is the interesting one here. You tried  to send an email down an encrypted tunnel but you can't. Even though both servers could. Now POODLE is bad an all, but really, if two SMTP servers are trying to send email to one another via an encrypted tunnel and they fail back to plain text to avoid POODLE what good does that do? POODLE is a  man-in-the-middle attack vector, and you could argue that you have no idea where your SMTP transaction is going, but that's really all I can come up with for causing "fail back to plain text". It's not like you have your SMTP edge gateway servers sitting in a Starbucks hanging off their public wifi (if you are, then you really should disable SSLv3).

As President Obama used to say about same sex marriage, my thoughts on this are still evolving, but it sure feels like disabling SSLv3 on an SMTP server may lead to some unexpected results.

If your SMTP edge server is Domino, then you may have issues leaving STARTTLS enabled (as outlined by Frank Paolino) until IBM release the multi-protocol fix (which I think maybe in the 9.0+ fix, it's starting to get confusing about what fix is going where). But this goes back to my main point....in Frank's case ProofPoint have disabled SSLv3, so now Frank has to send plain text email to ProofPoint.

So, I'll throw this out to the world in general....what are you doing for STARTTLS?
Darren Duke   |   October 23 2014 11:47:17 AM   |    domino    |   Comments [1]

Behold, the silence has ended.....the crescendo that is IBM has finally lifted the veil on some fixes for some very large security holes....AFAIK these are native Domino fixes for all platforms. I'm unsure of the protocols supported, but my understanding is all of them, but only time will tell.

These are not available yet, but should be in "weeks"...

First up, fix POODLE outlined in Technote 1687167. This is coming to:
  • 9.0.1 FP2
  • 9.0
  • 8.5.3 FP6
  • 8.5.2 FP4
  • 8.5.1 FP5

I think that is every supported Domino platform.  

Second is SHA2 support and TLS 1.2 support, as outlined in Technote 1418982. This is coming to
  • 9.x

This is great news, however if you need TLS 1.2 or SHA2 on 8.5.x you are out of luck....but you can still use my reverse proxy for that scenario.
Darren Duke   |   October 21 2014 10:53:44 AM   |    domino    |   Comments [3]

Update 12/12/2014 : If you are using this or any other Apache proxy, disable RC4 in the SSLCipherSuite line (change from RC4 to !RC4) and restart Apache, that will get you back to an "A" on the SSL Labs test. Note RC4 is *required* for XP and IE.....

Update 01/14/15 : Once you install the proxy, change the SSH Host Key as outlined here if-you-are-using-my-reverse-proxy-please-change-the-ssh-host-key.htm....

In an effort to help Domino customers mitigate the disaster that is the SSLv3 Poodle bug, I am providing the virtual machine linked at the bottom of this post. Note, you can also use the IBM HTTP Server bundled with R9 if you are on a Windows server....if that is the case, stop reading.

YOU USE THIS POST AT YOUR OWN RISK. For professional services related to this contact STS Sales.

Take backup copies of any files you change, including the Domino Directory. That way if you screw up......

Read this in it's entirety before you start.....it is not for the faint of heart. I take no responsibility for you screwing up your environment. None.

This VM is an Ubuntu 14 LTS server (patched as of Oct 15th 2014) with Apache installed in a way to allow easy integration as a reverse proxy for a Domino server. This allows the user to disable SSLv3 and utilize TLS 1.0, 1.1 and 1.2  thus mitigating Poodle. The apache server will use the best cipher for the client connecting to it, so it will prefer TLS 1.2 if the browser can support it.

No warranty is implied or provided. You use this VM at your own risk. There is no guarantee this will fix any and all security problems. It is suggested that after install you check your installation here https://www.ssllabs.com/ssltest/index.html (although at the time of writing the test site didn't indicate SSLv3 as an issue....IT IS).

OK, so what do you have to do to get this thing working.....

1) You need to be able to install OVF virtual machine templates. If you don't have a virtual infrastructure then this may not help
2) You have Domino working as a web server, or iNotes, or Quickr, or Traveler
3) You want to fix the Poodle bug and you can't or won't wait for IBM to address this properly
4) You don't need Windows XP with Internet Explorer support (this VM uses SNI, XP with IE can't do SNI although I believe Firefox and Chrome on XP can....). If you need XP support I may create another VM. You never know.
5) You don't mind changing the HTTP settings of your domino servers, including adding new DNS records to your internal DNS servers.
6) You want to address Poodle, SHA2 and/or add TLS to Domino.

If all of these are a check marked, continue reading....

The VM contains one Apache site capable of handling three different scenarios, iNotes, Quickr and Traveler.

1) Go download the VM here (there is no warranty, implied or given by use of this VM)
2) Install the VM on your virtual hardware
3) Power up and log in (default is root/root)
4) Change the default password using the passwd command
5) Change the IP address assigned to the machine with vi /etc/network/interfaces command (change all of the settings here to match your network). If you don't know vi then google it.
6) Reboot
7) Get an Apache compatible SSL certificate from your provider. If you need to create a new CSR do not use Domino to do this, but rather use OpenSSL (installed on this VM if you don't have an installation). Your SSL vendors site will have instructions on how to do this, here are GoDaddy's instuctions. When you have the key file and the signed certificate for your site, sites or wildcard copy them to the /etc/apache2/ssl folder (your provider will also give you a "bundle" certificate, copy that over too).
8) Use WinSCP to log into the VM and navigate to /etc/apache2/sites-enabled and double click on the combined.conf

Image:Here is a freely available VM to reverse proxy Domino - shoot the poodle
9) The first two virtual hosts (signified by the tag) are iNotes, the second two are Quickr, the third pair is Traveler. If you don't need a particular host (you don't use Quickr for example), simply delete everything between the two corresponding and tags (including the tags themselves). TAKE A BACKUP FIRST....you might do this wrong.

iNotes: Image:Here is a freely available VM to reverse proxy Domino - shoot the poodle

Quickr: Image:Here is a freely available VM to reverse proxy Domino - shoot the poodle

Traveler : Image:Here is a freely available VM to reverse proxy Domino - shoot the poodle

10) Edit the file changing at least anything with an IP in it, anything with a domain name in it, anything with a server name in it and anything with an SSL certificate in it. Here is what needs to be changed for iNotes:

a) Take a backup of the Domino Directory before you change anything.....I'm not going to outline the Domino part, I figured if you're reading this you know that part.
b) Our Domino server was called webmail.yourdomain.com. We are now moving this name to Apache and have changed the Domino HTTP server to domino1.yourdomain.com.  (if you don't know how to do this, stop and hire me via the link above)
c) Our Domino server was also using HTTPS, but now we've turned this off for Domino and only HTTP is in use on Domino.
d) There is also a new internal DNS entry pointing domino1.yourdomain.com to the Domino server IP (this is not an external DNS entry, only internal).
e) Externally, webmail.yourdomain.com points to Apache (in this case
f) Make sure you can ping the new domino1.yourdomain.com address from both the Apache server and the Domino server.

Remember, there are two Apache virtual hosts per Domino server....one that maps to HTTP that in turn redirects to the second one that handles HTTPS....

Below are the iNotes HTTP virtual host changes:

a) The vitual host address needs to the be the IP address of this VM
b) The host name's should match whatever URL your users use to get to iNotes, in this case webmail.yourdomain.com

Image:Here is a freely available VM to reverse proxy Domino - shoot the poodle

Below are the iNotes HTTPS changes:

a) The vitual host address needs to the be the IP address of this VM
b) The host name's should match whatever URL your users use to get to iNotes, in this case webmail.yourdomain.com
c) The SSL certificates need to match the ones you copied to the SSL folder, also update SSLCertificateChainFile to your providers bundle
d) The iwaredir.nsf needs to be changed to match your web mail redirector NSF file name
e) The ProxyPass and ProsyReversePadd host names need to be changed to your new iNotes server internal name (note this is also now a HTTP link, not HTTPS)

Image:Here is a freely available VM to reverse proxy Domino - shoot the poodle

11) Save the file
12) Restart Apache with the command /etc/init.d/apache2 restart
13) If you get errors, double check everything......and make sure to delete the vitrual hosts you don't need....like Quickr and Traveler for instance. After any changes restart apache
14) If it still doesn't work check the error log at /var/log/apache/ and look at the iNotes files.
15) If it still doesn't work then revert back to your original setup (I did tell you to take backups) and hire me.
16) At some point in the future, prevent Domino HTTP from being accessed anywhere but from the VM IP address.

This proxy has several advantages to IBM's approach of bolting IHS in front of Domino:
1.        You can have one and only one SSL certificate. I have a single wild-card certificate installed on the proxy and all proxied connections use this single certificate. That makes changing to SHA2/256 really, really simple.
2.        You don't have to patch server after server after server. One proxy, one set of patches.....heartbleed and shellshock anyone?
3.         I have significantly reduced my surface area on the web. Now all web servers traffic, be it Domino, Traveler, IIS or any other server are no longer directly connected to the evil internet.

In case you missed the link above, download the VM here (there is no warranty, implied or given by use of this VM).

AGAIN, you do this at your own risk. Unless your paying me to do this for you. you are on your own.
Darren Duke   |   October 15 2014 08:00:27 AM   |    domino  apache    |   Comments [4]