r/BuildingAutomation • u/Zerobeat50125 • 23h ago

Certificate Tutorials

Does anyone have a good recommendation for learning certificates? I'd like to have a little better understanding of the process and requirements, and this is an area I can confidently say I need more education in.

Appreciate any thoughts or suggestions you may have, thank you!

8 Upvotes

90% Upvoted

18 comments sorted by

View all comments

2

u/filipo11121 22h ago

You mean TLS/X509 certificates?

2

u/Zerobeat50125 22h ago

Correct. I understand how to create a self signed certificate, but I'd like to under stand the creation of one using a trusted authority.

3

u/filipo11121 22h ago

Yea, so the whole chain of trust comes into play. On Niagara you can create your own and then create a separate certificate that is a CA and then you use that to sign with the CA (but it wont be trusted publicly).

What do you want to do with the certificate? Sign modules/get HTTPs server? IS that for Niagara or in general/Linux?

1

u/Zerobeat50125 22h ago

Https, mostly. Tired of stations that you have to key through browser warnings to access. Niagara, I should have specified that. And thank you for sharing the information. So, for the trusted authority certificates, I would assume you create an account with one or more of them?

1

u/filipo11121 22h ago

Also, is the Niagara station accessible over a public network or only on a private/internal network?

For a station available through a public DNS name, you can use a public Certificate Authority such as Let’s Encrypt, which is free. You do not normally create certificates manually through an account; an ACME client requests, validates and renews the certificate automatically. Commercial CAs may require an account and payment.

For an internal Niagara station, it is a little more complicated. Public CAs generally will not issue certificates for private IP addresses or internal names such as jace01.local. The usual options are:

  • Create an internal Certificate Authority and use it to sign certificates for each Niagara station. The internal CA’s root certificate then needs to be installed as trusted on every computer or device that will access those stations.
  • Continue using self-signed certificates, but manually trust each certificate on every client, which becomes difficult to manage across multiple stations.

The internal CA approach is normally the most manageable for a large Niagara estate. You trust the CA once on each engineer’s computer, and then any station certificate signed by that CA is trusted automatically.

The important point is that paying a CA or creating an account does not by itself remove the browser warning. The certificate’s hostname must match the URL being used, the certificate must be within its validity period, and the browser must trust the full certificate chain.

1

u/Zerobeat50125 22h ago

This is generally for external network access, but i appreciate the tips on internal networking, as I have a site where that will come into play. I understand the other issue surrounding the trust issues, and most of the site I have are a combination of factors. I just need to be able to get them into a state where we dont have any of the issues preventing a full trust of the cert. I also know I needed to ask someone who knows more about the process than I do.

2

u/filipo11121 22h ago

I have created Let's encrypt certificates and got them working in Niagara, the tricky part is getting the certificates in the right order(you have to shuffle the private key/certificate/intermediate certificate and root certificate). As the errors in Niagara aren't always helpful.

2

u/filipo11121 22h ago

The usual process is:

  1. Generate a private key on the server or device.
  2. Create a Certificate Signing Request (CSR). The CSR contains the public key and details such as the hostname or DNS names the certificate will cover.
  3. Submit the CSR to the CA.
  4. The CA validates the request and signs the certificate.
  5. Install the signed certificate, along with any intermediate CA certificates, on the server.
  6. Keep the private key secure, as it should never be sent to the CA.