Query results for : HTTPServer
Domino Security - Disable HTTPEnableConnectorHeaders NOW- 9 November 2015 - (0) Comments
Thomas Hampel9 November 2015
There is a seucrity issue with Domino which allows anybody to gain access without authentication.
Jesper Kiaer wrote about this problem before in his blog post ( Part1 and Part2 ) and also created a video showing the problem.
If the Notes.ini variable HTTPEnableConnectorHeaders is set to 1, an attacker just needs to pass the user name he wants to be within a request header to get unauthorized access to Domino servers.
This notes.ini variable is referenced in the product documentation as well as in this technote for configuring Domino servers behind an IIS reverse proxy.
So there is a good chance that some people have enable this variable in production.
None of the Domino servers I have checked was affected, however I was able to reproduce the findings and can confirm it is working as described even with Domino 9.0.1 with latest fixes installed.
Steps to reproduce
- Add the Notes.ini variable "HTTPEnableConnectorHeaders=1" to the Notes.ini of the Domino server
Remark: This will make the server insecure.
- Restart the HTTP task
- Use Firefox and install this plugin => https://addons.mozilla.org/en-US/firefox/addon/modify-headers/
- Restart Firefox for the plugin to be initialized
- In Firefox, open the configuration of the new plugin
- Add a new header called $WSRU with the desired username / shortname as available in the target environment
Save + Enable the configuration
- Start the Plugin
- Navigate to an existing Domino server resource, e.g. https://your-domino-server.your-domain.com/mail/username.nsf
Just imagine what can be done when using the name of an administrator...
How to fix it?
Well, as simple as removing the Notes.ini variable in question, using the following two commands at the Domino server console:
set config HTTPEnableConnectorHeaders=0
tell http restart
tell http restart
Of course you would use a configuration document in production to keep your Notes.ini under control.
- Nevermind.dk - http://nevermind.dk/
- Sean Cull - Apache Proxy for Domino and HTTPEnableConnectorHeaders
- Darren Duke - If you get page errors after disabling HTTPEnableConnectorHeaders in Domino, try this
- Jesse Gallagher - Domino's Server-Side User Security
IBM HTTP Server - iKeyman with support for CMS is already part of your Notes Client- 22 September 2014 - (1) Comments
Thomas Hampel22 September 2014
Following up on David's post, here is a WIMP's Guide to get a GUI version of an iKeyman which is supproting the CMS format that is used by the IBM HTTP Server.
iKeyman is actually part of your Notes Client, it is available in "
So what does it take to add support for the CMS format
There is a (much) longer method to get the same done by downloading a specific version of ikeyman which includes CMS support... but this I'll explain at the end of this post.
Here is the short version:
What you need:
- Notes Client (which you should already have installed)
- Text editor of your choice
- Edit the file
- Find the list of security providers, e.g. by searching for "security.provider", which should look like this:
- Append one new line at the end of this list, where [X] is the next integer value available
So it should look like this:
# List of providers and their preference orders (see above):
Voila: CMS support is ready
This blog post could end here but I'd like to share what someone would have to do without using the method above:
The (very) long route:
- Try downloading IBM HTTP Server from www.ibm.com/software/webservers/httpservers/download or here
- Recognize this website only offers version: 126.96.36.199 dated from 15 May 2009
- Try anyway and download and install v7.0.0
- Notice iKeyman in this version does not Subject Alternate Support
- Read Technote 1444027
Notice it clearly describes "later versions of IBM HTTP Server (IHS), after v7.0, do not require these special steps to enable SAN functionality."
- Conclude the Technote 1444027 is wrong or needs update
- Try downloading t he IBM HTTP Server trial 8.0 or 8.5
- Notice the web site does not offer a download link and only shows a blank page (why?)
- Get IBM HTTP Server in the latest version, (which is part of Websphere Application Server 8.5.5 Supplements disks, so its just 3 Gbyte to download)
- Install the IBM Installation Manager v1.8 and add the WAS Supplements folder location as a new repository
- Install IBM HTTP Server
- Launch iKeyman with CMS support and Subject Alternative Support
- Notice that iKeyman is actually part of the Notes Client anyway and the same could have been done without all those actions before: priceless
Creating a certificate request incl. Subject Alternate Names can be done by using the GSKTool command line version
/opt/IBM/HTTPServer/bin/gskcapicmd -certreq -create -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd -label foobar -dn "cn=www.foobar.ibm.com" -size 2048 -file /tmp/foobar.csr -san_dnsname "www.foobar.ibm.com" -san_emailaddr "email@example.com" -san_ipaddr "192.168.1.221"
- Wikipedia Article subjectAltName
- GSKCapiCmd User's Guide (for GSKit version 8)
- Blog post IBM HTTP Server / IBM Global Security Toolkit - Commanding the line by David Hay
IBM HTTP Server - SSL Handshake Failed and why it matters to keep a backup of the key ring file- 20 September 2014 - (0) Comments
Thomas Hampel20 September 2014
All of a sudden (as usual) clients started to receive SSL expiration warnings when accessing the customer's Connections environment.
A quick look into the log file /opt/IBM/HTTPServer/logs/error.log confirmed the SSL certificate has expired.:
[Sat Sep 20 22:21:05 2014] [error] [client 10.175.198.62] [8222a80]  SSL0221E: SSL Handshake Failed, Either the certificate has expired or the system clock is incorrect. [10.175.198.62:40028 -> 10.175.220.11:443] [22:31:05.000019743]
Opening the *.kdb file with the gsktool showed the default certificate had expired.
Ok, nothing easier than that... so lets create a new signing request and get this signed by the certificate authority.
Once that is completed we can import the new certificate incl. any trusted roots quickly.
However when you try to import/receive your signed certificate keep the following in mind:
- You can only import a signed certificate into >exactly< the same *.kdb file which was used to create the certificate request.
Within the iKeyman utility, switch from "Personal certificates" to "Personal Certificate Requests" (sorry, only got screenshots in German available and hope the translation is correct)
normally it would look like this...
but if it looks like the following screenshot, then bad luck... you can not import your signed certificate anymore.
Instead you'll see "The certificate request created for the certificate is not in the key database" / "Die für das Zertifikat erstellte Zertifikatsanforderung ist nicht in der Schlüsseldatenbank vorhanden."
Now your options to solve this are:
a) find the original key ring file (*.kdb) which was used to create the certificate request
b) create a new certificate request, but this time make sure to keep the *.kdb file
c) set up a self signed certificate - although this is an option, it should not be considered
d) update the SSL directives on your IBM HTTP Server and set SSLClientAuth to "noverify". This will not fix the problem but will at least allow the server to be up and running with an expired certificate until you have obtained a new one.
(...if there are other options, please let me know)
- Keep the key ring file backed up
- Track certificate expiration time
- When expired, take action well in advance
- Even when delegating simple work, supply detailled instructions on least 250 pages
Why do I need to troubleshoot such a very very basic problem myself on a Saturday night?