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.