In the world of computer to computer communication, security is paramount. In order to provide secure connections our server has to trust your server, and then encrypt traffic that passes between them. This article explains why you should send us your intermediary certificates and why relying on 'trust stores' being up to date is not enough.
Summary
We'd still encourage you to read the full article, but the main takeaway messages are:
- We don't hold any certificates that your IT teams may have created, so we are unable to tell you when they might expire.
- You need to make sure your system sends us valid and verifiable certificates.
- You should not expect us to have your Root or Intermediary certificates.
- You will need to make sure you procure a certificate that will work for as many systems as possible, otherwise you will encounter issues with different vendors.
Certificates
Certificates are digital credentials used by computers and systems to prove identity and establish secure, encrypted communication — for example, in SAML, HTTPS, or API calls.
Certificate Authorities (CAs) are trusted organizations that issue and sign these certificates. Their signature says, “We verify this certificate belongs to who it claims.”
Trust
Trust in certificates is established by having the certificate issued by a Certificate Authority. There might even be several layers of trust. This is called a Certificate Chain. In this chain there is the root certificate which is at the end of the chain, there are also intermediate certificates as different Certificate Authorities get involved in issuing certificates.
Establishing that YOUR certificate is valid, also means establishing that all the certificates in the chain are valid.
Operating System Trust Stores are built-in lists of trusted Certificate Authorities used by software on the system — for example, scripts, agents, or background services.
Browser Trust Stores are similar but used specifically by browsers, and may include or exclude different Certificate Authorities depending on the vendor (like Chrome or Firefox).
When one machine connects to another, it checks the other’s certificate. If it’s signed by a Certificate Authority in the trust store, the connection is trusted. If not, the connection fails or raises a warning.
Trusted Intermediaries
Intermediary certificates (also called intermediate certificates) act as links in a chain of trust between a root certificate and an end certificate (the one used by a server or service).
Here’s the simplest way to picture it:
1. Root Certificate – issued by a top-level Certificate Authority (CA), built into trust stores.
2. Intermediate Certificate – issued by the root, and used to issue other certificates.
3. End Certificate – issued by the intermediate, and used by a machine or service (e.g. in HTTPS or SAML).
This chain lets the root CA stay secure (rarely used directly), while intermediate CAs handle daily operations. When a machine receives a certificate, it checks the full chain:
End cert → Intermediate → Root. If it can follow that chain up to a trusted root, it accepts the connection.
“But it works for me!”
This is a common reaction when users are told a URL isn’t trusted. They try it in their browser or with cURL, and it works—so why the confusion?
The reason lies in intermediate certificates. These are issued by certificate authorities (like Let’s Encrypt) and sit between the server’s certificate and a trusted root. Since intermediates are reused across many sites, browsers and some systems cache them after first encountering them.
So, if your browser or OS has seen that intermediate before, it fills in the missing link in the trust chain and everything works. But on a system without that cached intermediate (like some Linux setups), the connection fails unless the server provides the full chain.
Talis Aspire Requirements
Here are a number of facts about certificate use in Talis Aspire that are important to be aware of.
- Your systems will host certificates and send them to us.
- You should send us full chain certificates where possible. Don't rely on us having your Certificate Authority (CA) in our trust stores. You might start using a CA that has not yet been included in our operating system builds. Additionally some of our applications operate in environments that do not have trust stores available.
- Do not expect us to manually add root or intermediary certificates to trust stores.
- In some security critical applications like our SAML Authentication system. We will configure the connection to recognise a specific certificate that is used to sign the metadata that shares additional certificates with us. There are multiple certificates involved, and if any of them can't be trusted your users will not be able to log in. If those certificates are change without telling us it will cause problems
- In LTI connections between your virtual learning environment and our application, certificates are used to share and sign the connection. If any of these certificates cannot be trusted, our system will reject the connection.
Debugging and Fixing issues
The best fix is for you to make sure that your certificates purchased from Certificate Authorities are as widely trusted by as many systems as possible.
You should use tools like Qualys SSL Labs to verify that your certificate chains are fully trusted in both browser and operating system environments.
Exactly how you fix any issues is not something we can help with because it depends what system you need to modify at the university. There are plenty of articles from security companies that can help with that depending on your situation.
Compare with an example of a good certificate
We take our own advice! You can see our Certificates have all the necessary intermediaries included. Look in the 'Certificate Paths' section of this report and you will see everything is green, or 'sent by server'.
https://www.ssllabs.com/ssltest/analyze.html?d=talis.com&s=23.185.0.2&latest