“Certificates, certificates, certificates! I do not want to hear another word about certificates!”, famous words from a frustrated colleague of mine. But the truth is that understanding how SSL certificates are used to secure HTTP communication is not always easy to understand. Security is always tricky and troubleshooting security issues is always a pain. This article will of course focus on Smart Office but almost everything described is valid for any web application as well.
General SSL information
HTTPS encrypts the traffic between the clients and the server and also prohibits man-in-the-middle attacks. To ensure server identity (prohibit man-in-the-middle attack), the server URL is included in the SSL certificate.
Even though this article is about Smart Office it is easier to troubleshoot and verify SSL certificates through a browser. If the browser can show a HTTPS URL without errors, Smart Office will not have a problem with the URL either.
To view an existing certificate used in a web-site, open up Internet Explorer and navigate to the HTTPS URL. In the example below I have used Google mail.
Click the padlock and then click View Certificates. It look slightly different on different Internet Explorer versions or if using some other browser.
There is some important information on the first tab.
The Issued to: field contains the URL that the SSL certificate is valid for. If accessing the machine through any other URL (IP or only “mail” if you happens to be on the google.com intranet) the browser will report an error. This means that for every server exposing a HTTPS connection a unique SSL certificate must be used. There is however one way to reduce the number of SSL certificates and that is to create a so called wildcard certificate. A wildcard certificate may have an Issued to value like *.google.com. Such a certificate could be used for all servers in the google.com domain. Using a wildcard certificate is less secure then using unique certificates.
Another feature of SSL certificates that can be useful is the ability to add on alternative names. If a server has one or more aliases in the DNS it is possible to create a SSL certificate that is valid for more than one URL. On the Details tab there may be a field called “Subject Alternative Name” that lists all the server names the certificate is valid for.
The certificate in this example is valid for both mail.google.com and inbox.google.com.
Now back to the General tab again.
The Valid from, to fields shows the date interval when the SSL certificate is valid. If the SSL certificate has expired the browser will show an error. It is the current date on the client machine that must be in the date interval.
The Issued by: field shows the certificate that has issued (created) the certificate. A self-signed certificate would show the same name in the Issued by: field as the Issued to: field.
On the Certificate Path tab the whole certificate chain is shown.
The top most certificate, “GeoTrust Global CA” in this example, is called the root-certificate and must be in the Trusted Root Certificate Authorities list in Windows. If the certificate is not in the list, the browser will show an error when connecting to the HTTPS URL.
Fortunately Microsoft is maintaining this list for us for all the bigger commercial root certificates and is pushing them out to all Windows operating systems through patches. A root-certificate is always a self-signed certificate.
Short summary on what must fulfilled in order for a valid HTTPS connection.
- The HTTPS URL must be exactly as the Issued to field or any of the alternative names.
- The root-certificate must be in the Trusted Root Certificate Authorities list in Windows.
- The current date of the client machine must be in the Valid from, to interval of both the SSL certificate and the root-certificate.
Note that the port number is not include in the SSL verification, that means that the same SSL certificate can be used for all HTTPS endpoints on a machine regardless of which port they use.
View Windows Certificates
To open the Certificates tool show above, open a CMD window and type mmc.exe and press enter. The Microsoft Management Console should be shown. Select File->Add/Remove Snapin… Select Certificates and press Add, select Computer account and press Next. Select Local computer and press Finish.
|Mode of acquisition||Advantages||Disadvantages|
|Issued by a third-party vendor.||Works for clients from any domain.||Additional expense; delivery time gap.|
|Issued by an in-house certificate authority||Inexpensive; automatically applies to all clients in the internal network.||Configuration and maintenance of certification server is needed; applies only to domain clients.|
|Self-signed certificate||Inexpensive and easy to use especially for test environments.||Must be installed at all client machines. Not secure.|
Self-signed certificates are almost never used together with Smart Office and is not discussed in this article.
Recommendations on when to buy or when to use an in-house Certificate Authority comes in the next section.
Infor Smart Office and Infor ION Grid
Infor ION Grid (Grid) is the application container where the Smart Office server is running.
When installing Grid it will actually create its own root-certificate and use that certificate when issuing all other certificates in the Grid, you can say that the Grid has its own Certificate Authority. For each Grid Host there is a SSL certificate created and all Grid Routers on that host will use the same SSL certificate (in future Grid versions there may be an option to change SSL certificate per Grid Router).
In Grid 1.11 the SSL certificates key-stores are located on each Grid Host in the folder <LCM service>\grid\<Grid name>\grids\<Grid name>\secure\ The key-store file-name is https.ks and the key-store password is stored in https.pw. The key-store is a java key-store that can be manipulated with the JDK tool keytool.exe. The only time necessary to manipulate it manually is when wanting to re-use an existing SSL certificate.
For Smart Office to be able to use an out-of-the-box installation the Grid root-certificate must be placed in the Trusted Root Certification Authorities list in Windows. There is an instruction at the end of this blog post on how to do that.
Using an out-of-the-box installation that requires manual steps to start Smart Office may be cumbersome if having many users. Especially if the users do not have that much computer skills or if the users do not have administrative rights on their computers.
There are a few different ways to make it easier for the users, which way to go depends on how Smart Office is going to be used and the intranet infrastructure already in place at the customer.
- Is Smart Office going to be used over open internet? If yes, I recommend buying a certificate from a third-party vendor. Securing Smart Office and Grid to be used over open internet requires some serious configuration and is not covered here.
- Does the customer have an in-house Certificate Authority?
If yes, use it to create SSL certificates. Both Windows server 2008 and Windows server 2012 comes with a Certificate Authority.
If no, can the customer install one?
- As a last way, it is possible to distribute the Grid root certificate through a Windows policy. How to distribute a certificate is describes in the Smart Office administration guide or google it.
There are instructions in the Infor ION Grid Security Administration Guide on how to make a certificate request through the Grid Configuration Manager and how to import the actual certificate after it is created by the Certificate Authority.
Smart Office requires that all communication between the Smart Office client and the Smart Office server is made over HTTPS. Smart Office features, like the M3 MForms and the Lawson SForms, executing inside of Smart Office may or may not require HTTPS even though the recommendation is to always use HTTPS. Each Smart Office Feature normally has its own section in the Profile Editor URLs where URLs to back-end system is configured.
The general recommendation is to use at least 2048-bit key for a SSL certificates but there is more than just the key size that makes a connection secure. Read more in this article http://www.symantec.com/connect/blogs/ssl-ciphers-beyond-private-key-and-certificate
Here are also some other interesting links that can be worth reading.
Appendix: How to install the Grid root certificate
Easiest way of installing and the Grid root-certificate is to go to the Smart Office installation page, normally something like http://server.company.com:port/mango and right-click on the text Install Infor Smart Office and select Copy link address.
Paste the link in text editor and find and copy the value of the SERVER parameter, something like https://server.company.com:port
Start an Internet Explorer as an administrator and navigate to the copied SERVER URL, the Grid information page should be shown and there should be a certificate issue.
Click the Certificate error and click View Certificates, select the Certification Path tab and select the root-certificate and click View Certificate.
In the new Certificate dialog click Install Certificate…. In the Certificate Import Wizard select Local Machine and click Next. Select Place all certificates in the following store and click Browse… In the Select Certificate Store dialog check the Show physical stores checkbox and select Trusted Root Certification Authorities->Registry
Click OK, click Next, click Finish. Click Yes in the Security Warning.
Close all dialogues and all open Internet Explorers. Open an Internet Explorer and try the server URL again, there should be no certificate issues.