Log Insight 4.0 changed the default option of “ssl” from off to on as I covered in this post. Using encryption by default is a best practice, but you should be aware of the four SSL parameters that can be set in the [server] section of the Log Insight agent configuration. Read on to learn more!
Some people talk about security, many people skimp on security, few do security right. Of course, security has many meanings, but in this post I will be discussing physical and online security of data. With the amount of data available today, it is critical that we all take security seriously. In this post, I would like to talk about some of the security issues I have had in the past and a few of my approaches to ensure better security of my data. Read on to learn more!
Log Insight 3.0 agents support SSL for both the cfapi and syslog protocols. In this post, I will discuss how to configure the agents to properly communicate over SSL.
I just concluded a three part series on how to backup and restore Log Insight. I just realized that I missed how to backup and restore the SSL certificate on the Log Insight virtual appliance. I will address this oversight in this post and then update the previous posts.
As you know, Log Insight is primarily used through its HTML5 interface. By default, Log Insight ships with a unique SSL certificate per appliance. The Administration section of the Log Insight UI allows a user to upload a PEM certificate to use in place of the self-signed certificate. In this post, I would like to discuss operations you may desire to perform in regards to SSL in Log Insight as well as share a script on how to properly manage all the available options.
I was recently asked to assist in configuring a wildcard SSL certificate on a pair of vCloud Director (vCD) cells. While the certificate had been installed on the cells, some browsers were displaying SSL errors such as the following:
|While other browsers appeared to work:||Until you drilled down a little further:|
In addition, while uploading/downloading VMs SSL errors like the following were displayed:
So what was going on and how can it be fixed?
So, you are ready to purchase SSL certificates, did you know that not all SSL certificates are created equally? Let me start by taking a step back and asking an easier question, do you want your site to be available with and without a leading ‘www.’? Many people may not even consider the latter question relevant, but I assure you it is. Some people have a preference in that they always want the URL to either include the leading ‘www.’ or remove it while others do not care and want them both to work. In either case, a SSL problem may exist depending on the issuer of the SSL certificate.
The problem with supporting multiple host names over SSL on the same server is that they each require a unique, static IP address. As many of you probably know, static IP addresses are not cheap and are not easy to come by. In order to get more than a single static IP address a justification form usually needs to be filled out. One thing you may not know about IPv4 addresses is that they are quickly running out. As such, anything that can be done to use these addresses more efficiently would be beneficial to all until IPv6 becomes more commonly used.
For those interested in using SSL certificates, I would like to bring up two very important things to keep in mind:
- Under most circumstances, each site that utilizes a SSL certificate must have a unique, static IP address
- All SSL certificates are not the same so be sure you understand what type of certificate you are purchasing
Before purchasing or beginning to architect your domain supporting SSL, I encourage you to read and fully understand how SSL works. In order to support valid SSL authentication on all operating systems and web browsers, each domain that utilizes a SSL certificate must have a unique, static IP address assigned to it. In addition, the web server application used must be configured at a minimum to use IP-based virtual hosts.