SSL/TLS certificates
Knowledge shared by Oren
This knowledge sharing article will cover:
- Crash course on SSL/TLS Certificates
- Lessons learned from last week installation
- How v20.3 installation kit will make our life easier with certificates
The following explanation is in my own words.
This topic is very complicated, I personally learn new things all the time, so I tried to simplify the explanation in the price of being not so accurate here.
What is the difference between SSL and TLS?
It is the same thing actually. SSL is the old standard name, and TLS is the new standard name. SSL counts today as very not secured,
but everyone are still using this name as it was the first.
The latest version of TLS is 1.2 . before it there were TLS 1.0 and 1.1, both counts as not secured anymore.
There is a new version of TLS going to be released soon, TLS 1.3 . the standard is not finalized yet, so it is not GA.
You can enable and disable in Windows registry if you want to allow the machine to use which version of SSL and TLS.
Certificates in the worlds of Windows and Linux:
Windows OS manages all its certificates in a storage called “Certificate Store”.
All Applications that are Windows “native” will usually work with this Store to validate certificates.
Linux OS does not have any type of certificate store. Certificates are managed as simple files.
All applications that were developed to support Linux will work with certificate files.
Our Kryon RPA contains both “Windows native” components that can work only with the “Windows Certificate Store”,
and some components (RabbitMQ, NginX, Aerobase) that originated from Linux, so they can work only with certificate files.
How do you generate a certificate and why the hell it is never simple?
First you need to understand what is a “CA” – Certificate Authority.
sounds big, but I see it as a “special certificate to generate real certificates”.
anyone can create its own CA. (AKA “Self-signed”)
So if anyone can create its own CA, can anyone create its own certificate? Yes. (AKA “self-signed”)
So can I generate a CA of “Google.com” and then a certificate in the name of google.com ? yes.
So where is the security here?
It is all about “Who knows your CA”.
When a client machine uses a browser to go to google.com, and the browser sees this website has a certificate,
the browser must check if it is a valid certificate. It does it by checking its CA – who generated this certificate.
How CA is being validated?
Windows “native” applications will validate the CA against the Windows Certificate Store in the client machine – CA must be installed in the Windows Store to count as “Valid”.
Linux-originated applications will require the CA (“public”) key to be accessible as a file so it can validate it.
There is a list of global, all known, CAs, like GoDaddy, Digicert, and many more.
Microsoft pushes updated to this global CA list through Windows update to everyone.
So that means that if I create my own CA, I must make sure all the client machines that are going to use the certificate that was generated with this CA will be installed on the client machines Windows Certificate Store, or else – the certificate is useless (AKA “big red warning in the browser”).
So what types of CA do we have?
Global all known CA – automatically known by all clients thanks to Microsoft
Custom CA – Organizations can generate their own CA for their internal organization use, and make sure it is deployed to all the client machines in their organization.
Non valid CA – a CA that was created but is not installed on the client machine so it is not valid.
Important: certificates that are generated by both “Custom CA” and “Non valid CA” might be referred as “Self-signed certificate”, even though the result will be totally different.
Actually, from client machine perspective, there is no difference between “Global all known CA” and a “Custom CA”. certificated that were generated by both CA types are valid in the same level.
What are all these certificates file formats?
There are many formats for files that are related to certificates. I will focus only on the ones that we use at Kryon.
*.CRT – the certificate itself. Can be installed as a certificate.
*.KEY – the private key that was used to generate the certificate
*.PFX – a bundle file that contains both CRT and KEY.
*.PEM – contains the CA (public) key. (this is how we use it in Kryon. PEM is much more than this)
So why it is so complicated to generate a certificate that will simply work?
The options and parameters to generate a certificate are almost endless.
you can take a look at the guide of OpenSSL – the most common tool in the world for certificate generation:
https://www.openssl.org/docs/man1.0.2/man1/openssl.html
you can also google “OpenSSL” to find the endless online guides for creating and managing certificates.
There is a good reason that many IT people in large organizations are getting tangle with this.
Certificate is all about security and encryption methods.
Modern browsers and security hardening settings today are enforcing standards for certificates.
Each certificate has several properties and attributes. If something is missing or not perfectly in place – the whole certificate is “disqualified”, and now go figure why it was not qualified and what was missing.
There are also many file formats for certificates, which does not make it easier.
Lessons learned last week – installation of v19.5.1:
Kryon RPA server installation can accept certificate in two formats:
1. PFX
2. CRT + KEY + PEM
When providing PFX, the workflow in the installation kit was as follows:
1. Validate PFX in different ways
2. Extract CRT+KEY+PEM from the PFX and save them in local folder (ProgramData)
3. Install the certificate in the Windows Store.
4. Pass the CRT+KEY+PEM to Aerobase/Nginx/RabbitMQ components.
5. save in registry the location of the CRT+KEY+PEM files for future installation re-run.
When providing CRT+KEY+PEM, the workflow in the installation kit was as follows:
1. Pass the CRT+KEY+PEM to Aerobase/Nginx/RabbitMQ components.
2. save in registry the location of the CRT+KEY+PEM files for future installation re-run.
Lesson learned #1 – no validation was done in case CRT+KEY+PEM files were provided.
Lesson learned #2 – even if PFX was provided, when re-running the installation, it will take by default the CRT+KEY+PEM path, and it is better keeping the original path
Lesson learned #3 – upon re-run of installation, if new PFX was provided, the installation will always take the CRT+KEY+PEM files that were generated/provided in the previous installation run, which did not allow to “fix” the certificate without deleting the old CRT+KEY+PEM files first.
Lesson learned #4 – When CRT+KEY+PEM files were provided and not PFX, apparently the KEY file can be generated encrypted with password (as it happened by this customer), and the installation kit did not support such case, and did not warn (see lesson learned #1).
Hopefully we will be able to push a fix for 20.3 for all the above issues.
How v20.3 will be our life easier with related to certificates?
- Many customers will want to generate a certificate using their own CA, but many are getting tangle with the certificate generation part.
- Now the installation can do it for them:
- The installation can generate a certificate based on the CA that is provided by the customer, and save all the trouble of certificate generation.
- The installation can now generate on-the-fly both CA and certificate.
- the deployment of the CA that was generated to the client machines can be in one of the following methods:
- The RPA server installation generates MSI wrappers for Robot and Studio installation, and this MSI will ship also the CA to the client machines.
- The RPA client will know to validate the CA automatically without requiring the CA to be installed in the Windows Store.
