SSL Certificate Basics and FAQs

SSL certificate basics and frequently asked questions

• SSL Certificate
• Cert
• OnPrem 

Informational

SSL Basics:

• In its most basic form, an SSL certificate simply verifies that you are where you think you are.
• For example, if I go to www.tylertech.com, an SSL certificate verifies the identity of the website. The URL I visited is www.tylertech.com and the SSL certificate was issued to *.tylertech.com and I trust the issuer of the certificate, so everything checks out and I don't get any certificate errors.
• It is the responsibility of On-Premise clients to renew their certificate with their vendor.

Certificate Fields:

• Issued To: This specifies what URLs the cert can be used to secure. 
  • For example: 'munis.tylertech.com' can be used to secure 'munis.tylertech.com' but not 'munis2.tylertech.com'
  • Wildcards are noted by * and are all inclusive.
    • For example: '*.tylertech.com' can be used to secure anything from 'munis.tylertech.com' to 'xyz.tylertech.com'
• Issued By: This specifies who issued the cert.
  • You must trust the issuer to not have cert problems. 
  • For example: Most third-party certs are issued by a major vendor such as GoDaddy, Network Solutions, etc. and most computers will trust these certs as they often inherently trust the major cert vendors. 
  • If you purchased a cert from a lesser-known vendor, or created your own cert, then the computers would need a certificate installed to say that the PC trusts certs issued by that certificate authority.
• Validity Period/Valid from: This is when the cert is valid to and from.
  • Outside of this date range, the cert will cause errors.
• Subject Alternative Names: In the Details tab of the Certificate Viewer, there should be a [Certificate] Subject Alternative Name field. 
  • This can be used to specify additional DNS entries that the cert can be used to secure.
  • For example: rather than a wildcard cert, you might buy a cert that says 'Issued to: munisapp.yourdomain.org' and in the Subject Alternative Name field it also has entries for 'munis.yourdomain.org', 'munistrain.yourdomain.org', and 'munistest.yourdomain.org'.
  • Note: This field is required by most modern web browsers, including Chrome, even when using a wild card certificate. If this field is not present, applications may not work in some browsers.

 FAQs:

Do I need IIS installed to create a Certificate Signing Request (CSR)?

• No. Clients should have their SSL certificates procured prior to their engagement with Tyler. Since Tyler installs IIS for the client, this is a common question. Below are two articles that step you through creating a Certificate Signing Request without IIS (through the Certificates.MMC). CSR’s should always be created using the Certificates.MMC. CSRs that are created through IIS do not result in an SSL certificate that includes a Subject Alternative Name field, which is a required field for most modern browsers.
• http://www.entrust.net/knowledge-base/technote.cfm?tn=8924
• https://social.technet.microsoft.com/wiki/contents/articles/10377.create-a-certificate-request-using-microsoft-management-console-mmc.aspx

Do I need to go through the Certificate Signing Request (CSR) process on the servers that will be using the certificate(s)?

• No, it does not need to be done on the machine that will be using the cert. The CSR process can be completed on any machine via the Certificates.MMC as long as it is initiated and completed on that same machine. In other words, you could start and finish the CSR process on a machine before you've even built the servers that are going to use the certificate(s).

Why won't my certificate show up as an option in IIS?

• For certificates to be usable in IIS and Apache, the private key must be included. If the private key is included, you will see the message below when looking at the properties of the cert. If you do not see that, it will not be usable in IIS and will not show as an option in the dropdown. If the private key is included, it almost always means a password is needed to install the certificate. This will be needed by Tyler as well.

I have a wild card certificate already; can we just use that?

• Yes, so long as you understand the implications of DNS. For example, your public facing website is 'yourdomain.org' and you have a wild card cert for '*.yourdomain.org'. Everything on that domain is publicly facing and therefore DNS is managed externally. All of your internal network uses 'yourinternaldomain.org'. In this example, you can use the '*.yourdomain.org' for your internal traffic, but since DNS is currently being handled externally and you don't want these to be public facing DNS records, you would need to create an internal DNS zone for '*.yourdomain.org'. This also means any DNS records that already exist for public facing resources would need to be replicated for your internal DNS, otherwise your internal PCs won't be able to reach the public facing resources.

Is there a public key length requirement?

• Yes. All certificates should have a public key length of 2048 bits or higher.

 

Does case sensitivity matter?

• Yes, case sensitivity can matter in some scenarios. As a result, it is best practice to use all lowercase since end users are unlikely to use capitalization when entering URLs. For example:

'munisapp.yourdomain.org' – Good

'MunisApp.YourDomain.Org' – Bad

My internal domain ends with .local and I cannot purchase a cert for that domain OR someone else already owns the domain I want to use, what can I do?

• As of 11/1/2015, any DNS entry with a non-public domain name suffix (i.e. .local, .internal, etc) cannot have a certificate issued to it by a public certificate authority. This means if your internal domain is 'mydomain.local' then GoDaddy cannot sell you a cert. Likewise if, internally, you use 'mydomain.org', but another company owns that domain name publicly, then you will not be able to purchase a cert for it.
• In these scenarios, you would either need to:
  • 1) purchase an available domain, get a cert(s) for it, and setup DNS for it, or
  • 2) you can continue to use your existing domain, but since you cannot purchase a cert for it, you would have to issue you own cert(s) with your own certificate authority or use a self-signed cert(s).

Does my internal and external traffic have to use the same cert?

• No. Internal and external traffic can be treated independently from each other. They could use the same domain and the same certificate or they could be completely different from each other. A common scenario would be a site using an internally generated cert to secure their internal traffic on a domain called 'yourdomain.local' while their externally facing traffic (such as Munis Self Service) uses a certificate they purchased from a third party on a domain called 'yourdomain.org'.

Examples:

*Note: the above chart assumes that there are no entries in the 'Subject Alternative Name' field. Any entries that exist in that field would also be securable.

Updating SSL Certificates on Tyler Servers