Revisit: Wildcard SSL certificate from P12/PFX file into Domino

Posted by:

The objective of this article is to provide an example on how to  do this with hopefully no discussions and no questions unanswered. Of course this example is based on a particular situation with a special certificate provider but can hopefully be translated to any other situation with other certificate authorities.
Wrote an earlier article, this is an update

1. Assumptions
2. What do I need
3. OpenSSL
4. Kyrtool
5. Syntax
6. Example
7. Implement the files on the server
8. Check out if it works
9. Important note
10. Conclusion

Running Windows 64 bits (directory separator = \)
PFX file contains both certificate, intermediate and root certificates 
Domino server running 9.0.1 FP3

What do I need:
1. An exported P12/PFX file from in my case IIS, containing the wildcard certificate private key as well as the certification path to it.

2. OpenSSL:
Easy precompiled:
The one I used:

3. Kyrtool:
Fixcentral short:
Fixcentral long:

<ossldir> = Where you installed OpenSSL eg. C:\OpenSSL-Win64
<pfxdir> = Where you have placed your pfxfile
<pfxfile> = Name of your pfxfile eg. wildcard_acme_com.pfx
<pfxpassword> = Password to your pfxfile
<pemdir> = Where you have placed your pfxfile
<pemfile> = Name of your pfxfile eg. wildcard_acme_com.pem
<notespgmdir> = Notes or Domino program directory, minimum 9.0.1 FP3
(assumes that notes program directory is in your path, if not execute from program directory)
<kyrdir> = Directory where you want to put your kyrfile
<kyrfile> = Name of your kyrfile eg. wildcard_acme_com.kyr
<kyrpassword> = Password to your kyrfile

Check your pfx file:
<ossldir>\bin\openssl pkcs12 -info -in <pfxdir>\<pfxfile>
use <pfxpassword> when asked (nothing on PEM)

In general:
1. <ossldir>\bin\openssl pkcs12 -in <pfxdir>\<pfxfile> -out <pemdir>\<pemfile> -nodes -chain
use <pfxpassword> when asked (nothing on PEM)
2. <notespgmdir>\kyrtool create -k <kyrdir>\<kyrfile> -p <kyrpassword>
3. <notespgmdir>\kyrtool import all -k <kyrdir>\<kyrfile> -i <pemdir>\<pemfile>
Check in general:
1. <notespgmdir>\kyrtool show certs -k <kyrdir>\<kyrfile> >kyrcerts.txt
2. <notespgmdir>\kyrtool show keys -k <kyrdir>\<kyrfile> >kyrkeys.txt
3. <notespgmdir>\kyrtool show roots -k <kyrdir>\<kyrfile> >kyrroots.txt

1. C:\OpenSSL-Win64\bin\openssl pkcs12 -in C:\mypfxfiles\wildcard_acme_com.pfx -out C:\mypemfiles\wildcard_acme_com.pem -nodes -chain
use <pfxpassword> when asked
2. C:\IBM\Lotus\Domino\kyrtool create -k C:\mykyrfiles\wildcard_acme_com.kyr -p password
3. C:\IBM\Lotus\Domino\kyrtool import all -k C:\mykyrfiles\wildcard_acme_com.kyr -i C:\mypemfiles\wildcard_acme_com.pem
Check sample:

1. C:\IBM\Lotus\Domino\kyrtool show certs -k C:\mykyrfiles\wildcard_acme_com.kyr >wildcard_acme_com_kyrcerts.txt
2. C:\IBM\Lotus\Domino\kyrtool show keys -k C:\mykyrfiles\wildcard_acme_com.kyr >wildcard_acme_com_kyrkeys.txt
3. C:\IBM\Lotus\Domino\kyrtool show roots -k C:\mykyrfiles\wildcard_acme_com.kyr >wildcard_acme_com_kyrroots.txt

Implement the files on the server
1. Copy kyr file and the associated sth file to the server
2. Add the kyrfile name to your internet sites document or server document depending how your server is configured
3. Modify the cipher part
4. Make sure the SSL port is enabled in the Internet Ports.. section
5. Restart your http task on the server, use sh ta onl and check that http listens to both 80 and 443

Check out if it works
1. Use your browser and connect to your server via https
2. Look at your certificate information
3. Congratulations

Important note:
Following this means that especially the pem file is unprotected, therefore make sure that keep it in a safe place during this and maybe deleting it afterwards. Same goes for kyrfile (you can not delete them but keep them as safe as you can) as they contain private key.

Doing this task is not more complicated than any other task that involves certificates using any other platform.

Link to this document:



IBM Sametime Media Manager and the importance of the FQDN

Posted by:

To be able to deliver audio and video services with IBM Sametime 8.5.2 you have to install the Sametime Media Manager Server. The Sametime Media Manager uses the Session Initiation Protocol (SIP) to provide Sametime clients with support for peer-to-peer VoIP, video chats and for web conferencing within the meeting rooms. For security it uses by default TLS encryption to secure audio/video communication.

Then installing Sametime Media Manager you have several choices to make, should you install all three components (SIP Proxy/Register, Conference Manager and Packet Switcher) on the same server or should you install them on three different machines? Should you install it in DMZ for external access or not? One thing that is VERY important then installing, is which FQDN (Fully qualified domain name) your are going to use for Sametime Media Manager. So why is this so important? Its because of this:

The installer program for Sametime Media Manager uses the operating system machine name FQDN to create a self-sign certificate which later is used for TLS encryption!

This means that if you install Sametime Media Manager on a Windows 2008 R3 server which machine name FQDN is, the self-sign certificate will get created with that FQDN. To get audio/video to work between two Sametime clients, both clients needs to “connect” or register with the Sametime Media Manager. The Sametime client does this by asking its Sametime Community Server which FQDN to use for connecting to the Sametime Media Manager. In this case the Sametime client will use the FQDN

OK, but what If I does not want to install Sametime Media Manager using the operating system name. Say you like to use a DNS Alias, which are quite common then installing application servers. What will happens then?

If you install Sametime Media Manager using a DNS Alias (like the certificate used for TLS encryption of A/V will still use the FQDN . Then a Sametime client then tries to create a A/V session with another Sametime client, the A/V session will fail because the client will try to use the FQDN , but the certificate used for TLS encryption will only work if the Sametime Media Manager Server FQDN are…

This is the reason why IBM writes this in the “IBM Sametime 8.5.2 – Installation From Zero to Hero  – 8.5.2” presentation.

“…The Media Manager Server does not work when installing with a DNS alias. You
must configure the full qualified machine host name (including domain part)
and use this for the installation. This name does not need to be configured
anywhere else and the client does not see it.”

OK, so I need to install the Sametime Media Manager with its operating system FQDN. Is that so bad? No not if you are only going to use Sametime A/V on your intranet. Then it may be OK to use a OS FQDN. But if your Sametime environment also are going to be accessible from the Internet this will cause problems.

To be able to deliver Sametime A/V services between internal Sametime Servers/clients and external Sametime clients, you have to install a couple for Sametime Edge Servers in DMZ. Then you have to use a “split DNS” configuration so external clients can use the same FQDN to Sametime Servers as the internal Sametime clients. One of the Edge Servers you need to install in DMZ are the Lotus SIP Edge Proxy Server. This server must have the same FQDN as the Sametime Media Manager Server standing on the internal network!

Internal Sametime Client —> Sametime Media Manger ( —> | DMZ— Lotus SIP Edge Proxy Server ( …DMZ | <—  External Sametime Client

The above configuration demands that you put internal server names in the external DNS, and FW/DNS/network guys sometimes have a problem with that… So if you are going to deliver A/V services to Sametime clients on the internet, deciding the FQDN for the Sametime Media Manager Server when installing is VERY important.

You have to decide the following before installing Sametime Media Manager:
– Will we deliver Sametime A/V services to Sametime clients connected to the Internet?
– Is it OK to have intranet operating system machine FQDN in the external DNS?

OK, say that you answer yes on the first question and no on the second one. Well one of the solution then is to install the Sametime Media Manager with a FQDN which are OK to have in the external DNS. A FQDN like But then you may end up having trouble with the internal server management/monitoring teams. They may have strict rules about naming internal server names. Internal sub domains and so on. So what to do?

Well you could do this:

1. Set the operation system machine names FQDN to
2. Install Sametime Media Manager using the FQDN
3. After installation and configuration of Sametime Media Manager is complete, change the operating system machine name back to what is was before

This work around has been approved by IBM and I am going the try it on one of our customers next week. 🙂