Mobile API Gateway: Update certificates without redeployment
Article ID: 129119
Updated On:
Products
CA Mobile - APP Services
CA Mobile API Gateway
CA API Gateway
Issue/Introduction
The SSL certificate in the msso_config json file which is currently pinned by the mobile sdk is going to expire. In order to rotate to a new certificate a new app version needs to be rolled out. How can the certificate be updated without needing to update the app?
Environment
Mobile API Gateway 4.2
Resolution
There are three options for SSL pinning as noted in the documentation.
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/mobile-api-gateway/4-2/mobile-policies/configure-policies/login-authentication-and-authorization-policies/ssl-trusted-certificates-and-ssl-pinning.html
If the SSL certificate pinning option is chosen, it will always require the app to be updated with the new certificate in the msso_config.json and redeployed.
To avoid updating the app when the certificate is updated the other two options are more suitable but have security trade-offs.
1. SSL Trusted Certificates - The Mobile SDK evaluates the certificate presented by the server against the list of trusted root certificates on the device. If the certificate is not signed by a trusted Certificate Authority (CA), the connection is rejected. However, you have no control over the trusted CA's on the device so this could potentially cause issues
2. SSL Public Key Hash Pinning - The Mobile SDK extracts the public keys from the certificate from the server and validates against a list of strings that contains pinned public key hashes in base-64 format. Once the cert is updated the public key hash should remain the same so nothing new is required on the client-side.
It will be slightly less secure as this does not validate the validity period of the certificate and could be a problem if they sign the certificate with different key pairs.
Some have tried to use the enrollment URL to forcibly download a new msso_config.json dynamically.
To be clear, the enrollment URL was not designed for this purpose. This feature was originally designed and implemented for securing Mobile SDK bootstrap process so that the application does not contain any sensitive information in the app’s bundle.
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/mobile-api-gateway/4-2/mobile-policies/configure-policies/login-authentication-and-authorization-policies/ssl-trusted-certificates-and-ssl-pinning.html
If the SSL certificate pinning option is chosen, it will always require the app to be updated with the new certificate in the msso_config.json and redeployed.
To avoid updating the app when the certificate is updated the other two options are more suitable but have security trade-offs.
1. SSL Trusted Certificates - The Mobile SDK evaluates the certificate presented by the server against the list of trusted root certificates on the device. If the certificate is not signed by a trusted Certificate Authority (CA), the connection is rejected. However, you have no control over the trusted CA's on the device so this could potentially cause issues
2. SSL Public Key Hash Pinning - The Mobile SDK extracts the public keys from the certificate from the server and validates against a list of strings that contains pinned public key hashes in base-64 format. Once the cert is updated the public key hash should remain the same so nothing new is required on the client-side.
It will be slightly less secure as this does not validate the validity period of the certificate and could be a problem if they sign the certificate with different key pairs.
Some have tried to use the enrollment URL to forcibly download a new msso_config.json dynamically.
To be clear, the enrollment URL was not designed for this purpose. This feature was originally designed and implemented for securing Mobile SDK bootstrap process so that the application does not contain any sensitive information in the app’s bundle.
Feedback
Yes
No
Powered by
