# Secure Your Integration with Passwords or Certificates
source: https://developer.mastercard.com/mastercard-gateway/documentation/security-and-fraud/secure-int-pw-cert/index.md
You can authenticate to the Mastercard Gateway using passwords or SSL certificates.
## Password Authentication {#password-authentication}
You can enable secure access to the Mastercard GatewayAPI and Batch integrations through passwords. The system-generated password is a 16 bytes, randomly generated value that is encoded as a hex string. Though it is of sufficient length and quality to resist brute force guessing, it should be secured in the same manner as user passwords and other sensitive data.
Warning: Your password is a secret and should be known only by you and Mastercard. It is important to keep it confidential to protect your account.
### Generate a password for the API {#generate-a-password-for-the-api}
You can generate your API password in the Merchant Administration portal. As a prerequisite, your merchant profile must be enabled for **API** , **Batch** , and **"Use Password Authentication"** privileges.
To access the Merchant Administration portal, you need your login credentials. Administrator login credentials will be provided to you by your payment service provider when you are successfully onboarded to the gateway. As an administrator, you can create a new operator with permissions to generate the API password.
1. Log in to with your administrator login credentials.
2. Navigate to **Admin** \> **Operators**
3. Create a new operator by entering all the mandatory fields.
4. Assign the **"May Configure Integration Settings"** privilege to enable the operator to generate the API password.
5. Log out of Merchant Administration and log back into the Merchant Administration portal as the new operator.
6. Navigate to **Admin** \> **Web Services API Integration Settings** \> **Edit**.
7. Click Generate New and select the **Enable Integration Access Via Password** box.
This is the API password that you use to authenticate API requests made from your web server to the gateway.
8. Click **Submit**.
You must always have at least one password generated and enabled but you may have up to two passwords set up. For security, you should change the password periodically. Only one password must be used for configuring your application, the second one working as a standby for password rolling purposes.
After the system creates the password, you need to include it in every transaction request you send to the Mastercard Gateway.
* If you are using the REST-JSON format, include your User ID and password in the Standard HTTP basic authentication header of the request.
* If you are using the NVP format, include two additional parameters in the request: `apiUsername` and `apiPassword`.
To authenticate as a merchant:
* The username must start with merchant.
* The password must be the one the system generated for you.
**Password API Reference** [\[REST\]](https://developer.mastercard.com/mastercard-gateway/documentation/api-reference/v100/rest/api-ops/index.md#transaction) [\[NVP\]](https://developer.mastercard.com/mastercard-gateway/documentation/api-reference/v100/nvp/api-ops/index.md#transaction)
## Certificate Authentication {#certificate-authentication}
Alert: Certificate authentication is currently not supported with [Batch](https://developer.mastercard.com/mastercard-gateway/documentation/integrations-types/hosted-batch/integrate-hosted-batch/index.md) or [Reporting](https://developer.mastercard.com/mastercard-gateway/documentation/gateway-features/data-and-reporting/reporting/index.md) APIs.
The host name for certificate authentication is different from **{{host}}/api**. Contact your payment service provider for the host name.
To use certificate authentication with the Mastercard Gateway, you need to present a valid digital certificate.
These certificates are issued by trusted organizations called Certificate Authorities (CAs). The CA confirms that the certificate's public key is valid, belongs to the correct person or organization, and is not altered or replaced by a malicious third party. This process is part of a security system called Public Key Infrastructure (PKI), which helps protect your data by ensuring it stays private, accurate, and secure.
Warning: Mastercard no longer accepts certificates issued by Entrust due to security concerns. To maintain a secure connection, always use a certificate from DigiCert, a trusted Certificate Authority (CA), when creating or renewing your server certificate. For a full list of Certificate Authorities, see [List of certificate authorities](https://developer.mastercard.com/mastercard-gateway/documentation/security-and-fraud/secure-int-pw-cert/index.md#list-of-certificate-authorities).
The authentication mechanism for certificate authentication requires both the client (your Web Server) and the server (Mastercard Gateway) to present certificates to authenticate themselves. This is termed as mutual authentication, the workflow for which is illustrated here.
The steps for connecting to the Mastercard Gateway using certificate authentication are:
1. The client requests a connection to a protected resource on the server.
2. The server presents its certificate chain back to the client.
3. The client verifies the server's certificate using a trust store, which contains the trusted root CAs. The client validates the server certificate path to a trusted CA root certificate.
4. If successful, the client sends its certificate chain to the server. The client stores its certificate in a key store. Note: Depending on your Web Server client software, the trust store and key store are often the same.
5. The gateway verifies the client's certificate using the full set of trusted and approved CA root certificates that are loaded on to the server. The following checks are performed:
**a.** Check if the certificate is in X.509 certificate format.
**b.** Validate the certificate path to a trusted CA root certificate.
**c.** Check that the certificate has not expired.
**d.** Verify that the client certificate has a Key-Usage extension, marked critical that includes client authentication as a permissible use of the certificate.
**e.** The subject common name of the client certificate is confirmed to match the subject common name configured for the merchant in the gateway.
The subject common name of the certificate must contain the legal business name of the merchant.
**f.** Check if the presented certificate matches the status of the merchant profile. A production profile only accepts production certificates while a [test profile](https://developer.mastercard.com/mastercard-gateway/documentation/testing/test-your-int/direct-payment/index.md#testing-tools) accepts either test or production certificates.
If these steps are successful, then the merchant authentication is successful, otherwise the connection is rejected by returning an appropriate error message.
6. If all the checks outlined in step 5 are successful, then the server accepts the connection and allows the request to proceed.
### Getting a Test and Production Certificate from a CA {#getting-a-test-and-production-certificate-from-a-ca}
Before going live with your production certificate, you can develop and test PKI authentication with a test certificate. This may be useful, for example, where you do not wish to share the production certificate and private key with a third-party web integrator.
It is important that the certificate you procure from your chosen CA meets Mastercard's requirements of certificate implementation. Here are some key points to consider when you procure your SSL certificate.
* The certificate must be in X.509 certificate format.
* The certificate must have a **Key-Usage** extension marked as critical, and include client authentication as a permissible use of the certificate.
* The certificate must be issued by a CA approved by [Mastercard](mailto:gateway-support@mastercard.com). Contact Mastercard to get a list of approved CAs.
* The subject common name (CN) of the certificate must contain the fully qualified domain name (with or without a wildcard) of the website the certificate is being purchased for.
* The subject organization (O) field must contain the organization of the merchant.
### Configuring Merchant Certificates in Merchant Manager {#configuring-merchant-certificates-in-merchant-manager}
After procuring the certificate from a reputable CA, your payment service provider must configure either your test, or your test and production certificate in the Merchant Manager portal, as part of configuring all the API settings for your merchant profile on the gateway. If required, a merchant certificate may be linked to multiple merchant profiles from the same business or across businesses. For more information on how to configure merchant certificates in Merchant Manager, see the API Configuration section in the Merchant Manager User guide.
The site controls the list of acceptable CA root certificates that are used to verify merchant certificates. To verify the certificate, the system collects the PEM encoded version of the production certificate through Merchant Manager. The Subject Common Name (CN) is extracted from this certificate and verified against the Subject Common Name of the presented certificate during the SSL handshake.
Warning: When you renew your certificate, ensure that the full subject string or line contains the CN, O, L, ST, and C fields are in the same order with the same values.
### Integrating the SSL Certificate into your application {#integrating-the-ssl-certificate-into-your-application}
After configuring the certificate against your merchant profile, you must perform the following steps to install the certificate in your environment.
1. You need to give your SSL software access to both the private key and the certificate so it can connect securely to the Mastercard Gateway. Depending on the software, the private key, certificate and associated certificate chain may need conversion to a supported format. For example, private keys and certificates are often provided in text files, in PEM format, with the private key protected by a password. In Java, these files are typically loaded into a Java key store. Check your SSL software documentation for supported formats.
Alert: For Java and .NET environments, we recommend that you convert the PEM files to PKCS12.
2. In almost all cases, the issuing CA for your certificate also provides additional certificates known as a certificate chain. Provide these to the Mastercard Gateway during the SSL handshake to enable the gateway to validate your certificate. Your SSL client software has instructions on how and where to place these certificates.
3. A simple test to check if your certificates are set up correctly: load them into a web browser, then visit the Mastercard Gateway test URL to see if it responds with its status. If the certificates are correctly loaded, accessing the Check Gateway URL causes the browser to prompt you to select, or accept the certificate to use for connecting with the gateway. If your browser prompts you and a successful connection is achieved you get the following response: {status: "OPERATING"}.
Warning: Most browsers also require the PEM formatted certificates to be converted. So, using the browser to test the correct certificates will also confirm you can successfully convert the certificates to the appropriate format. Internet Explorer supports the following formats, PKCS#12, PKCS#7 and Microsoft Serialized Certificate Store. The OpenSSL utility is an excellent tool for converting between PEM formats and PKCS-based formats. **Check Gateway URL API Reference** [\[REST\]](https://developer.mastercard.com/mastercard-gateway/documentation/api-reference/v100/rest/api-ops/index.md#gateway) [\[NVP\]](https://developer.mastercard.com/mastercard-gateway/documentation/api-reference/v100/nvp/api-ops/index.md#gateway)
### Rolling Certificates {#rolling-certificates}
You may wish to roll from the existing certificate to a new certificate for various reasons. For example, upgrading a certificate for a change in company name or rolling from a test certificate to a production certificate.
To roll to a new certificate, your payment service provider must add the new certificate as a primary certificate while the old certificate becomes an additional certificate. You can have one or more additional certificates. Merchants that are configured to use the new certificate may authenticate to the API using either the old certificate or the new certificate.
This is meant to be a temporary configuration until all integrations have been upgraded to use the new certificate. For more information on how to add additional certificates, see the API Configuration section in the Merchant Manager User guide.
## Session Authentication {#session-authentication}
Session authentication uses the gateway [payment session](https://developer.mastercard.com/mastercard-gateway/documentation/integrations-types/hosted-session/integrate-hosted-session/create-payment-session/index.md), a temporary container for request fields, to authenticate the merchant. Because the merchant is already verified using a password or certificate, the customer (payer) can use the session to interact with the Mastercard Gateway, for example, to complete authentication steps.
This authentication mechanism allows payers to provide their payment details directly to the gateway. The payer data is obtained through a client-side interaction with the gateway, either through the payer's browser or an app on the payer's mobile device. It provides a simple integration model to securely obtain the required payer data as the API requests to the gateway are performed directly from the client than from your server.
It uses a basic HTTP authentication mechanism (similar to password authentication) where you must provide a "merchant.{your_merchant_id}" in the userid portion and the session ID in the password portion.
Warning: Session authentication is only available from API v55 onwards.
To use session authentication:
1. Create a session by submitting an API ***Create Session*** request from your server to the gateway server. This operation returns a session ID.
2. Submit the ***Update Session*** request using session-authentication to add any relevant data to the session created in Step 1.
3. Provide the session to the payer.
### Supported transactions {#supported-transactions}
The following Operations support authentication using a session ID.
* ***Update Session***
* ***Initiate Authentication***
* ***Authenticate Payer***
### Payer input and output fields {#payer-input-and-output-fields}
In session-authenticated interactions with the gateway, the payer is restricted to a subset of fields within an API operation. These are referred to as payer input fields. If you provide fields other than payer input fields in a session-authenticated request, the request is rejected. For example, the payer cannot submit data such as the order amount.
Similar to payer input fields, the gateway allows only certain fields to be returned in the response for a session-authenticated interactions with the gateway. These are referred to as payer output fields, only fields that are required to be displayed to a payer on a browser or an app to perform a transaction are returned. For example, security sensitive data such as the session ID is not returned.
##### Update Session {#update-session}
* `billing.address.city`
* `billing.address.company`
* `billing.address.country`
* `billing.address.postcodeZip`
* `billing.address.stateProvince`
* `billing.address.stateProvinceCode`
* `billing.address.street`
* `billing.address.street2`
* `browserPayment.preferredLanguage`
* `correlationId`
* `customer.dateOfBirth`
* `customer.email`
* `customer.firstName`
* `customer.lastName`
* `customer.mobilePhone`
* `customer.nationalId`
* `customer.phone`
* `customer.taxRegistrationId`
* `device.browser`
* `device.browserDetails.3DSecureChallengeWindowSize`
* `device.browserDetails.acceptHeaders`
* `device.browserDetails.colorDepth`
* `device.browserDetails.javaEnabled`
* `device.browserDetails.language`
* `device.browserDetails.screenHeight`
* `device.browserDetails.screenWidth`
* `device.browserDetails.timeZone`
* `device.fingerprint`
* `device.hostname`
* `device.ipAddress`
* `device.mobilePhoneModel`
* `gatewayEntryPoint`
* `locale`
* `merchant`
* `order.id`
* `order.walletProvider`
* `session.version`
* `shipping.contact.email`
* `shipping.contact.firstName`
* `shipping.contact.lastName`
* `shipping.contact.mobilePhone`
* `shipping.contact.phone`
* `sourceOfFunds.provided.card.devicePayment.3DSecure.eciIndicator`
* `sourceOfFunds.provided.card.devicePayment.3DSecure.onlinePaymentCryptogram`
* `sourceOfFunds.provided.card.devicePayment.cryptogramFormat`
* `sourceOfFunds.provided.card.devicePayment.emv.emvData`
* `sourceOfFunds.provided.card.devicePayment.paymentToken`
* `sourceOfFunds.provided.card.expiry.month`
* `sourceOfFunds.provided.card.expiry.year`
* `sourceOfFunds.provided.card.mobileWallet.emv.emvData`
* `sourceOfFunds.provided.card.nameOnCard`
* `sourceOfFunds.provided.card.number`
* `sourceOfFunds.provided.card.provided.card.prefix`
* `sourceOfFunds.provided.card.securityCode`
* `sourceOfFunds.token`
* `sourceOfFunds.type`
* `transaction.acquirer.customData`
* `transaction.acquirer.traceId`
* `transaction.id`
* `correlationId`
* `error.cause`
* `error.field`
* `error.supportCode`
* `error.validationType`
* `order.amount`
* `order.currency`
* `order.customerNote`
* `order.customerReference`
* `order.invoiceNumber`
* `result`
* `session.updateStatus`
* `session.version`
##### Initiate Authentication {#initiate-authentication}
* `apiOperation`
* `correlationId`
* `order.walletProvider`
* `session.id`
* `session.version`
* `sourceOfFunds.provided.card.devicePayment.3DSecure.eciIndicator`
* `sourceOfFunds.provided.card.devicePayment.3DSecure.onlinePaymentCryptogram`
* `sourceOfFunds.provided.card.devicePayment.cryptogramFormat`
* `sourceOfFunds.provided.card.devicePayment.emv.emvData`
* `sourceOfFunds.provided.card.devicePayment.paymentToken`
* `sourceOfFunds.provided.card.number`
* `sourceOfFunds.token`
* `sourceOfFunds.type`
* `authentication.3ds2.methodCompleted`
* `authentication.3ds2.methodSupported`
* `authentication.redirect.customized.3DS.methodPostData`
* `authentication.redirect.customized.3DS.methodUrl`
* `authentication.redirectHtml`
* `authentication.version`
* `correlationId`
* `error.cause`
* `error.field`
* `error.supportCode`
* `error.validationType`
* `order.authenticationStatus`
* `order.currency`
* `order.status`
* `response.gatewayCode`
* `response.gatewayRecommendation`
* `result`
* `sourceOfFunds.provided.card.number`
* `sourceOfFunds.type`
* `transaction.authenticationStatus`
* `version`
##### Authenticate Payer {#authenticate-payer}
* `apiOperation`
* `billing.address.city`
* `billing.address.company`
* `billing.address.country`
* `billing.address.postcodeZip`
* `billing.address.stateProvince`
* `billing.address.stateProvinceCode`
* `billing.address.street`
* `billing.address.street2`
* `correlationId`
* `device.browser`
* `device.browserDetails.3DSecureChallengeWindowSize`
* `device.browserDetails.acceptHeaders`
* `device.browserDetails.colorDepth`
* `device.browserDetails.javaEnabled`
* `device.browserDetails.language`
* `device.browserDetails.screenHeight`
* `device.browserDetails.screenWidth`
* `device.browserDetails.timeZone`
* `device.ipAddress`
* `order.walletProvider`
* `session.id`
* `session.version`
* `sourceOfFunds.provided.card.devicePayment.3DSecure.eciIndicator`
* `sourceOfFunds.provided.card.devicePayment.3DSecure.onlinePaymentCryptogram`
* `sourceOfFunds.provided.card.devicePayment.cryptogramFormat`
* `sourceOfFunds.provided.card.devicePayment.emv.emvData`
* `sourceOfFunds.provided.card.devicePayment.paymentToken`
* `sourceOfFunds.provided.card.expiry.month`
* `sourceOfFunds.provided.card.expiry.year`
* `sourceOfFunds.provided.card.number`
* `sourceOfFunds.provided.card.securityCode`
* `authentication.3ds2.acsReference`
* `authentication.3ds2.challenge.signedContent`
* `authentication.3ds2.methodCompleted`
* `authentication.3ds2.methodSupported`
* `authentication.3ds2.sdk.interface`
* `authentication.3ds2.sdk.timeout`
* `authentication.3ds2.sdk.uiType`
* `authentication.3ds2.sdk.OobAppSupportsRedirectUrl`
* `authentication.payerInteraction`
* `authentication.redirect.customized.3DS.acsUrl`
* `authentication.redirect.customized.3DS.cReq`
* `authentication.redirect.domainName`
* `authentication.redirectHtml`
* `authentication.version`
* `correlationId`
* `encryptedData.ciphertext`
* `encryptedData.nonce`
* `encryptedData.tag`
* `error.cause`
* `error.field`
* `error.supportCode`
* `error.validationType`
* `order.authenticationStatus`
* `order.currency`
* `order.status`
* `response.gatewayCode`
* `response.gatewayRecommendation`
* `result`
* `sourceOfFunds.provided.card.number`
* `sourceOfFunds.type`
* `transaction.authenticationStatus`
* `version`
## Protecting payer information using SSL {#protecting-payer-information-using-ssl}
All websites collecting sensitive or confidential information need to protect the data passed between the payer's Internet browser, the application and the Mastercard Gateway.
SSL is a security technology that is used to secure web server to Internet browser transactions. This includes the securing of any information (such as a payer's credit card number) passed by an Internet browser to a web server (such as your web "Shop and Buy" application). SSL protects data submitted over the Internet from being intercepted and viewed by unintended recipients.
When implementing the Direct Payment, you must ensure that your application presents a secure form using SSL. Also consider using a secure form in your application when collecting confidential information such as payer addresses.
### How do my payers know if my site is using SSL? {#how-do-my-payers-know-if-my-site-is-using-ssl}
Whenever an Internet browser connects to a web server (website) over https:// - this signifies that the communication with the Mastercard Gateway will be encrypted and secure. You can alert your payers to this, fact so they know what to look for when transacting on your website.
## Reference Table of Key Differences Between Security Models {#reference-table-of-key-differences-between-security-models}
The following table outlines some key differences between password and certificate authentication models with the intent of helping you choose the authentication solution that best meets your business' authentication requirements.
| | Password Authentication | Certificate Authentication |
|-----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **When to Use** | With small businesses where simple authentication meets the requirements. | With large enterprises where the cost of infrastructure to implement PKI is minimal against the security gained using a higher level of authentication. |
| **Technical Skills Required** | Requires knowledge of basic HTTP authentication | Requires knowledge of mutual authentication and PKI using Certificate Authorities |
| **Ease of Integration** | Easy to integrate | Setting up the keystore file and other infrastructure can add to the complexity of the integration. |
| **Level of Authentication** | Moderate | High |
| **Cost** | Least expensive authentication method to use. | Involves additional costs, such as the certifying authority's subscription cost for issuing the SSL certificates. |
| **Benefits** | Ideal for smaller merchants where the cost of integration is an important factor and business models do not require higher security levels. | SSL mutual authentication provides high security and is considered an industry best practice. It optimizes authentication performance by using the existing SSL connection, which is typically created anyway. The extra overhead of sending the client certificate is minimal. |
| **Disadvantages** | Password is embedded as cleartext in the HTTP authentication header and must only ever be sent over SSL. The Mastercard Gateway only accepts SSL-protected connections, thereby protecting the password from disclosure; however, it is important to the security of the connection that proper server authentication be performed to prevent accidental disclosure to rogue servers. | None |
| **Support for Sharing Credentials Across Multiple Merchant Profiles** | Cannot share passwords across multiple merchant profiles | Allows you to share a Certificate Set ID with multiple merchant profiles within and across MSOs (privilege-based). |
## List of certificate authorities {#list-of-certificate-authorities}
Warning: Mastercard Gateway does not recommend or endorse specific certificate authorities (CAs). The listed CAs are simply those currently integrated with the gateway. This list may change. To confirm a particular CA, contact [Customer Technical Support (CTS)](mailto:gateway-support@mastercard.com) or your technical account manager.
* DigiCert
* Trustwave
* Sectigo
* Entrust
* IdenTrust
* OpenTrust
* thawte
* Go Daddy
* SecureTrust
* Verisign
* GlobalSign
* certSIGN
* DIGITALSIGN
* ComSign
* eMudhra
* E-Tugra
* GeoTrust
* D-TRUST
* GLOBALTRUST (e-commerce monitoring GmbH)
* Baltimore CyberTrust
* GTS (Google Trust Services)
* WoSign
* COMODO
* CommScope
* Microsoft
* Amazon
* XRamp
* SwissSign
* SSL Corporation (SSL.com)
* HARICA (Hellenic Academic and Research Institutions CA)
* Japan Certification Services (SecureSign)
* Cisco
* UniTrust
* TrustAsia
* Deutsche Telekom Security GmbH
* Taiwan-CA Inc. (TWCA)
* T-TeleSec (T-Systems Enterprise Services GmbH)
* Swisscom
* Starfield
* SECOM
* QuoVadis
* OISTE
* Network Solutions
* NetLock
* AffirmTrust
* ISRG (Internet Security Research Group)
* Izenpe
* LAWtrust
* LuxTrust
* Buypass
* Disig a.s.
* Certigna
* Certplus
* Certipost
* Certum (Asseco Data Systems S.A. / Unizeto)
* AC Camerfirma, S.A. (Chambers of Commerce)
* USERTrust
* Atos
* Application CA (Japanese Government)
* Actalis
* BYTE
* EDICOM
* Verizon
* Microsec
* ANSSI
* Certainly
* Cybertrust
* Digidentity
* Halcom
* TunTrust
* Telia
* Symantec
* Chunghwa Telecom
* MULTICERT
* PersonalID
* vTrus(iTrusChina Co)
* ATHEX (Athens Exchange S.A.)
* America Online
* Australian Defence
* BJCA (BEIJING CERTIFICATE AUTHORITY)
* CFCA (China Financial Certification Authority)
* GDCA TrustAUTH (GUANG DONG CERTIFICATE AUTHORITY)
* CISRCA1 (Carillon Information Security Inc)
* S-TRUST (Deutscher Sparkassen Verlag GmbH)
* SAPO (South African Post Office Limited)
* SI-TRUST
* Skaitmeninio sertifikavimo centras (SSC)
* StartCom
* National Digital Certification Agency
* Swiss Government
* Swedish Government
* Thailand National Root Certificate Authority (Electronic Transactions Development Agency)
* TUBITAK Kamu SM
* Staat der Nederlanden(Government of The Netherlands)
* Krajowa Izba Rozliczeniowa
* Inera AB (SITHS)
* NAVER BUSINESS PLATFORM
* Hongkong Post
* Government Root Certification Authority
* RSA Security
* Firmaprofesional
* SCEE (Government of Portugal, Sistema de Certificação Electrónica do Estado)
* EE Certification Centre
* EC-ACC (Agencia Catalana de Certificacio)
* E-ME SSI (Sertifikacijas pakalpojumu dala)
* Correo Uruguayo
* Common Policy (U.S. Government)
* Certinomis
* AGESIC (Autoridad Certificadora Raíz Nacional de Uruguay)
* Autoridad de Certificacion Raiz del Estado Venezolan
* CNNIC (China Internet Network Information Center)
* I.CA (První certifikační autorita, a.s.)
* CONSEJO GENERAL DE LA ABOGACIA
* ACCV - Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
* DIRECCION GENERAL DE LA POLICIA
* Sociedad Cameral de Certificación Digital - Certicámara S.A.
* FNMT-RCM - Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
* ANCERT (Agencia Notarial de Certificación)
* ANF (Autoridad de Certificación)
### External Trust Store CA Bundle {#external-trust-store-ca-bundle}
* DigiCert Global G3 TLS ECC SHA384 2020 CA1
* DigiCert Global Root G3
* Amazon Root CA 1
* GeoTrust Universal CA
* Starfield Services Root Certificate Authority - G2
* VeriSign Class 1 Public Primary Certification Authority - G3
* VeriSign Class 2 Public Primary Certification Authority - G3
* VeriSign Class 3 Public Primary Certification Authority - G3
* VeriSign Class 3 Public Primary Certification Authority - G4
* VeriSign Class 3 Public Primary Certification Authority - G5
* VeriSign Universal Root Certification Authority
* thawte Primary Root CA - G2 DigiCert EV RSA CA G2
* thawte Primary Root CA - G3
* thawte Primary Root CA
* DigiCert Assured ID Root CA
* DigiCert Assured ID Root G3
* DigiCert Global Root CA
* Entrust Root Certification Authority - G2
* GlobalSign Root CA
* GlobalSign
* ISRG Root X1
* DigiCert Global Root G2
* SecureTrust CA
* USERTrust RSA Certification Authority
* SSL.com Root Certification Authority RSA
* DigiCert High Assurance EV Root CA
* Trustwave Global Certification Authority
* SSL.com EV Root Certification Authority RSA R2
* DigiCert Global G2 TLS RSA SHA256 2020 CA1
* DigiCert Assured ID Client CA G2
* DigiCert Assured ID Root G2
* Mastercard TST Application Infrastructure Root CA G2
* Mastercard TST External Customers Root CA G2
* Mastercard TST Mergers and Acquisitions Root CA