Yes, Part 1: this means that there will be (at least) a Part 2, and maybe more to come. Before each Open Horizons EMEA Summit Diethmar Rimser and I create a list of possible hotlabs. Beside the ideas of other speakers and the demands of Micro Focus we also try to produce some of our own proposals. How do I do it? Simple: I make a list of questions and problems that I’ve received in the past year from my customers and try to create some lab proposals out of that process. Before the most recent Open Horizons EMEA Summit it was clear to me that a lot of customers and administrators struggle with certificates. So a lab was born, and a few articles on this subject are the outcome.
For some strange reason certificates make administrators nervous. Is it because it’s about security, does it look complicated? I don’t know, I think it is because it’s something that you have to deal with, but not frequently, and unknown makes it unloved?
We as administrators, but also regular users, have to deal every day with certificates. So let’s try to clear the fog. I’m not a security expert. In these articles I try to approach this subject as a regular administrator. This means that I need to have some knowledge on the subject so that I can do my daily job, creating a secure network environment inside and outside my own network.
What are certificates?
When we think about certificates, in general we refer to creating SSL connections. SSL Certificates are small data files that digitally bind a cryptographic key to an organisation’s details. When installed for example on a web server, it activates the HTTPS protocol (over port 443) and allows secure connections from a web server to a browser. Typically, SSL is used to secure data transfer and logins, and more recently is becoming the norm when securing browsing of social media sites.
However certificates are used more than just for web browsers and web servers. You can use certificates to secure your SSH connection; certificates are used to secure traffic between Access Points and a Wi-Fi controller in the Wi-Fi world. There are a lot of other examples.
In general SSL Certificates bind together a domain name, server name or hostname, an organisational identity (i.e. company name) and location. An organisation needs to install the SSL Certificate onto its web server to initiate secure sessions with browsers. Depending on the type of SSL Certificate applied for, the organisation will need to go through differing levels of vetting.
Once installed, it is possible to connect to the website over https://www.domain.com, as this tells the server to establish a secure connection with the browser. Once a secure connection is established, all web traffic between the web server and the web browser will be secure.
Why do we need certificates?
A certificate is required in order to avoid the case that a malicious party which happens to be on the path to the target server pretends to be the target. This is what we call ‘a man-in-the-middle attack’. This is a process where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. There’s no need to explain to you that this can be a problem just if you think about the process of a login with a username and password (and that’s just a start).
How does it work?
Briefly, what happens if you switch from http to https? A browser will request a secure page, or secure connection, by switching the demand to the web server from http to https, or the web server can force the connection to an https connection. As a result of that switch the web server will send its public key with its certificate to the browser. And then the browser will do some checks (see below for more details); is the certificate unexpired or unrevoked; does the common name match, and was it issued by a trusted party?
If there are no errors, the browser will create and send a symmetric key to the web server. The web server decrypts this key using its own private key (remember that the web server has already sent its public key to the browser). The web server will send the requested page with the symmetric key to the browser. The browser decrypts the page and if all goes well you get the information you want, in this case a certain web page. (See figure 1).
Different components
It’s all about trust. But who is providing this trust? Probably you’ve already heard the terms Certificate Authority, Digital Certificates, Public Key and Private Key
Certificate Authority
A Certificate Authority or Certification Authority (CA) is an entity that issues digital certificates. Do you have a CA in your local network? If you use Open Enterprise Server (or still have NetWare servers) then the first server you ever installed is a CA in your network. Take a look in the Security Container in iManager and you will find the CA for your Tree (as shown in figure 2).
If you have SLES servers running and installed them more or less as default, there will be a CA on those servers (figure 3). So if you run OES on SLES, then you could have already two CAs in your local network.
Digital Certificates
A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. In this model of trust relationships, a CA is a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.
Again, if you run OES, by default the system creates some certificates for internal use (figure 4).
Public Key - Private Key
To build a secure channel, the system uses public-key cryptography, or asymmetric cryptography, a system that uses pairs of keys. In a public-key encryption system, any person or service can encrypt a message using the public key of the receiver, but such a message can be decrypted only with the receiver’s private key (see figure 1).
The strength of a public-key cryptography system relies on the degree of difficulty for a properly generated private key to be determined from its corresponding public key. Do the remarks 1024-bit key, 2048-bit key ring a bell? Security then depends only on keeping the private key private, and the public key may be published without compromising security.
The most common errors
For now we will only talk about web browsers and the errors and alerts they can give when somebody wants to create a secure connection and wants to use SSL /HTTPS.
Browsers tell visitors a website is SSL secure via several visible trust indicators. Depending on which browser and which version, the alerts can be obvious or can cause a lot of confusion. As an example I use an older alert message (fig. 5) and to be honest, almost nobody reads the alerts; everybody will add an exception; store the exception… and case closed, even if the alerts are relevant.
In this window we see that the browser does three checks; one is OK, two give an error.
- The security certificate was issued ……, this means that this browser has no clue about the CA that was used to create this certificate.
- The certificate date is valid. Each certificate has an end date, so certificates do not live forever, but this one is ok.
- The name on the certificate is not…. When you browse to for example https://192.168.10.83 but the certificate is created with the common name ‘oes.teaming.be’, then there is no match on the name and an error is produced.
What will most people do in general…. ‘Do you want to proceed?’…. Yes (and get me out of this nightmare).The most annoying thing for me in daily life as an administrator, but also as a user, is clicking away certificate errors/warnings.
How to solve certificate errors/warnings
In this example we use an OES2015 server and will try to get rid of the alerts that appear when somebody opens iManager.
So Firefox does not like the certificate info that it received. When you select Advanced it’s clear that the main alert refers to the issue that Firefox does not know the Certificate Authority (figure 7).
If you select ‘Details’, (Figure 8) more information on the issue is shown. And if you go for ‘View’ you get all the infrmation on the certificate. Most important are the Common Name, in this case oes.teaming.be and not 192.168.10.83 that we requested, and Issued By, the CA in the tree TEAMING (figure 9).
Every browser by default has a list of known CAs. So FireFox (and other browsers of course) ships with a default list of Certification Authority (CA) certificates. (For more info go to htttps://wiki.mozilla.org/CA:IncludedCAs for FireFox).
If you run your own CA then what we have in this case is that the browser cannot contact the CA because it’s not in the default list. But you can import your CA into the browser list, which makes your CA a trusted CA for your browser. If you use different browsers…. then you have to import the CA for each browser.
Import a CA
In this example we stay with FireFox and our own CA.
Part 1: Export. Exporting a CA is easy. Open iManager, go for Directory Administration and select Modify Object.
Search for your CA object in the Security Container and select it.
Select Certificates, mark the Self Signed Certificate, select Export - Do not select Export private key ! (see Fig 1), Save the export.
Part2: Import. Open FireFox and go to Options > Advanced > Certificates > View Certificates > Select Authorities and import the exported certificate. Now the browser, FireFox, has the CA in the trusted list.
Depending on how you access iManager in the future, by ipaddress or DNS-name, all alerts will be gone, and you will get a Green Padlock in front of the URL.
This is a small example of how to solve (stupid?) alerts. I agree, iManager is only used by administrators but other internal services for regular users may depend on your internal CA. If you manage to get your CA into the trusted list of the browser(s) …. you see the advantage?
In Certificate Nightmares – Part 2, I will discuss how to automate the import of a CA into FireFox, Chrome and Internet Explorer. Also in Part 2 the secrets on creating certificate requests will be revealed, together with how Tomcat deals with certificates and an overview of other alerts browsers can throw up. Part 3 will give an overview on how to deal with certificates and the renewal of certificates in the most common Micro Focus products.
This article was first published in OHM, Issue 33, 2016/2, p20-23