When connecting to Hubject, you may encounter multiple types of certificates. The precise setup depends on your infrastructure and may not be influenced by Hubject, as this would compromise the security of the connection. We enforce mTLS when partners call Hubject, but not for the reverse connection (when Hubject calls partners).
PLEASE NOTE: This article only covers the certificates used in eRoaming - Hubject Plug&Charge has a separate certificate management structure
When an EMP or CPO partner calls Hubject
1. Step 1: Partners must trust the Hubject certificate to avoid the SSL certificate error (see bottom of the page for the folder)
Relevant certificate: The Hubject certificate folder shared during the onboarding contains the Hubject Root CA and intermediate CA. As an online partner, you should use both and trust both. Add them into the trust store of your system, client libary etc. (Hubject NGINX checks if the certificate used is signed by that chain; in this case the signed client certificate)
Why? The Hubject Server certificate is not signed by a world-recognized CA that is installed as a standard on every machine - so partners have to trust our root certificate and intermediate certificate
Why should partners trust both? Partners need to trust both because one cannot trust the intermediate without trusting the root
Relevant error: if this step goes wrong, it will result in Error 400 - Bad Request: The SSL Certificate Error
2. Step 2: Partners must use their client certificate signed by Hubject in the header of the request to avoid Error 017
Relevant certificate: your signed client certificate (the result of your CSR submission)
Why? Hubject uses mTLS for this connection - we confirm that the client certificate matches the one we have on file for this tenant and confirm that it has been signed with our intermediate certificate
Relevant error: Error 017 - this indicates that there is a mismatch between the client certificate you used and the client certificate we have on file for your tenant.
When Hubject calls an EMP or CPO partner
When we act as a client, we call the partner - e.g. CDR forwarding to EMP, AuthorizeStart to EMP
Relevant certificate: Hubject client certificate. We do not send it because it was signed by the Hubject intermediate certificate, and you already trust this for the connection when you call Hubject.
Why? Hubject uses TLS for this connection. You should confirm that the certificate we send is signed by an authority you trust. mTLS or a reverse certificate chain are not supported for this connection due to system constraints.
Relevant error: No error, but also no message - if this part is not set up correctly, you will not receive API calls from Hubject.
Optional additional security measures
You may opt to verify the common name and DNS: service.hubject.com and qa-service.hubject.com
Please upload the certificate to the Certificate Management app in the portal if your URL is secured by a different CA other than Hubject. We trust the certificate uploaded there if we call the EMP partner. This certificate cannot be used as a client certificate because we do not have the private key. It cannot be used for mTLS.