It's recommended if reading part one to this guide if you haven't.
Part one can be found here.
Typically we need to get the customer or partner to request the creation of a certificate. We don't create them for clients directly, but we can give advice on what they need. Depending on the split of services over servers we need to get an SSL cert for:
Curator Gateway (the IIS server host and streaming host)
Curator Server Service (the service host)
and if Process Engine service doesn't reside on either of these, the two certificates above are installed on the Process Engine Server host so it can TRUST them)
In this guide, It's assumed we have each service on a separate server to explain the most complex setup, but if all of the above are on one host, it makes it MUCH easier.
Resolution.
Typically we want the system to have FQDNs for the hosts we are going to use, and DNS records that correctly map them for users, be this internal or external. For clarification, external access or the ability to qualify the hostname is ideal, e.g.
hostname.com or hostname.edu.company.com
We do not actively encourage or really want to support anything that tries to use internal-only domains, any domain admin worth their salt knows that this is now the most insecure thing in the world and will be actively using external lookups for FQDNs, but for clarity hostname.local or hostname.edu.company.internal is a huge no-no. The reason for this is that the DNS entry and server cannot be qualified by an external source, as such invalidating any certificate for true security purposes. We technically can do this, but it's not secure, and therefore invalidates the whole purpose of setting up HTTPS around authentication. Again, DON'T DO IT.
The best kind of SSL we want is a wildcard SSL, these however are very pricey and often unless money is no object, not used.
The breakdown of this will include the correct domain being used against the host, most admins will have DNS entries or alias in DNS to use the FQDN to point to a specific i.p address for your server.
A request to create a certificate starts with the name of the server or FQDN (Fully Qualified Domain Name).
Often we deal with i.p. addresses or server names directly, but for the certificate, we need to be specific.
Example One
Example Server name: CURATOR01
Services: IPV Curator Server Service
Domain: company,com
Example cert we need:
Single SSL: CURATOR01.company.com
or
Wildcard: *.company.com
Example Two
Example Server name: IISGATEWAY
Services: IPV Curator Server Service, Gateway/web streaming Services
Domain: subdomain.company,com
Example cert we need:
Single SSL: IISGATEWAY.subdomain.company.com
or
Wildcard: *.subdomain.company.com
NOTE: for every sub-domain, we must add this to our cert request, and our wildcard, if using the FQDN of IISGATEWAY.subdomain.company.com the wildcard *.company.com WILL NOT WORK, it must include the subdomain in it.
SANs (Subject Alternative Names)
Often when dealing with certificates, at an additional cost the client/cert creator can add SANs, these are embedded extra references to FQDNs or wildcard subdomains, that are not directly shown at face value when viewing a certificate.
If dealing with multiple servers and therefore multiple FQDNs, its more ideal to get a wildcard that covers the domain they all belong to, including subdomains. It's also a sensible option to also include the individual FQDNs in the SAN list.
Example:
We have 4 servers, Curator, Gateway, Streaming, Process Engine
All on a domain of: subdomain.company.com
We could create a certificate request for each individually:
curator.subdomain.company.com
gateway.subdomain.company.com
streaming.subdomain.company.com
processengine.subdomain.company.com
Or
We could create a wildcard cert with some SANs included:
Cert:
*.subdomain.company.com
SANs:
curator.subdomain.company.com
gateway.subdomain.company.com
streaming.subdomain.company.com
processengine.subdomain.company.com
This way we create one cert that can be used on all servers in that subdomain and we have specific references to them.
Depending on cost, split of services, and requirements, we can be flexible enough to create a cert for all locations required.
When a client has generated a certificate request, which can take an hour or up to a week, they will eventually get some certificates back from their chosen provider.
These can come in a number of extension varieties:
.pfx
.crt
.cer
If we require the cert for IIS integration for HTTPS websites and streaming we need to be able to import the certificate into IIS and it is trusted. If the IIS server was used to initiate a request, we can complete it with files from the client that will be used from the IIS prompt "Complete certificate request". Although this is a common way of getting certificates onto the server, it's the least preferred for us.
Ideally, we want a certificate with the extension .pfx to import into IIS, this would include a private key, which means we can import it to other servers, and not just the one server that requested the cert in the first place. This is an important key type for us when using wildcard certificates in particular since we want to use the same certificate in multiple servers.
You can see the difference between a cert that has a private key and not, indicated by its icon, which will have a key in the corner.
no private key
private key included
This also means we can EXPORT the certificate with all the required intermediaries' certs (used for validation) etc.
Typically when dealing with certificates that have private keys, often on import there may be a password associated with the key to ensure it's not being exported by just anyone.
Intermediaries are certificates in the .crt format from the valid provider of certs, they add a two-hop validation against certificates to ensure that the one generated is authentic from the said valid provider.
What to do if we only get a .cer or .crt:
To convert .crt to .pfx, we need the CSA certificate (Private Key) provided by the hosting provider. Below are the steps to convert this:
Download and install OpenSSL software from the below link based on your system type https://slproweb.com/products/Win32OpenSSL.html
- Navigate to the installation path and find the "start.bat" file, and execute in administrative mode, it will look like this:
- Note the path that the command prompt is pointing at, you can change this, or just be prepared to put your certificate files in this location, so we don't have to navigate around folder structures, so mine is c:\users\joe\
- Example from MDS client:
-
Run the following command in the command prompt:
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crtOR
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.txt -in certificate.crt -certfile CACert.crt
Here:
Certificate.crt = Your-domain-Name.crtCACert.crt = NetworkSolutions_CA.crtcertificate.pfx is the new name of the generated file.PrivateKey can be in .key or .txt format
Using our example files the command would look like this:
openssl pkcs12 -export -out qa-cs.ipv.mds.turner.com.pfx -inkey qa-cs.ipv.mds.turner.com.key -in qa-cs.ipv.mds.turner.com.crt -certfile globalsign-root-r3.crt -certfile globalsign-intermediate-rsa-ov-ssl-ca-2018.crt
After hitting Enter at this point, you may be requested to add the password used to create the cert request in the first place. Do so or leave it blank and hit Enter.
Once confirmed the new .pfx key will be created under the name you gave it in the command in the same folder as the certs used i.e. c:\users\joe\
The created certs can now be installed on any server that has the hostname or SAN, we can then also export this installed certificate (and include a private key) or directly install the pfx on servers that aren't in the SAN list or name, to be able to trust it. This is a KEY requirement for Process Engine if the service is not installed on the same server as Curator or IIS streaming services. Installing is as simple as right-clicking the cert on the desktop of the desired server, and choosing install, the default and automatic store they will be installed in are personal.
Please make sure if you install this way, that a copy of the same cert is in the trusted store as well.
Make sure all certs are installed under the local machine account and nothing else. To check or manually install do this via the windows MMC.exe snap in selecting the certificates snap in.
I can add how to do this in this guide if requested.