SSL Certificates Cloud - Application - and - Network - Security - Web - Protection - SSL - Tls - 2024-06-04
SSL Certificates Cloud - Application - and - Network - Security - Web - Protection - SSL - Tls - 2024-06-04
Contents
SSL/TLS Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Manage SSL Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
SSL Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Automatic Domain Validation for Imperva-Generated Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Upload a Custom Certificate for Your Website on Imperva. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ECC Certificate Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Upload a Certificate without a Private Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Upload a Custom Certificate with HSM Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Revalidate Your Imperva Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Adding Emails for Ownership Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Customize Website TLS Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Supported Cipher Suites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
CAA Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Client Certificate Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Client-to-Imperva Client Certificate mTLS Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Upload a CRL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Certificate Manager API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Certificate Manager API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Imperva-to-Origin Client Certificate mTLS Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
SSL Certificates API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
SSL certificates
To support secure websites (HTTPS), Imperva must host a valid SSL certificate for the website domain. Imperva
supports two types of certificates for this purpose:
• Imperva-generated certificate
Imperva-generated certificate
As part of the activation process, Imperva requires that a secure website add its domain to an existing Imperva
certificate. This certificate will be presented to any visitor trying to access your website, indicating that the connection
is secure.
The Imperva certificate is used by default for both SNI and non-SNI supporting clients. Server Name Indication (SNI) is
a TLS extension that enables a client to indicate the hostname it wants to connect to at the start of the handshake
process. Many older browsers do not support SNI. If you choose to provide us with your existing domain certificate in
addition to the Imperva certificate, your certificate is used for SNI-supporting clients, and the Imperva certificate
continues to be used for non-SNI supporting clients.
The process for adding your domain to an Imperva certificate is triggered automatically from the Add Site wizard
when you first onboard your website to Imperva, or using the Add site API. This process requires you to prove that you
are the owner of the domain you are adding to Imperva using one of the available methods:
• Email validation: A validation email will be sent to one of the email addresses associated with your domain. A
list of email addresses is displayed during the process. If the addresses are no longer in use or you wish to use a
different one, contact Support to request the change. The requested email address must be listed in your
domain’s Whois record.
• DNS validation: Imperva will provide you a TXT record with a unique DNS entry to add to your domain DNS
zone.
• CNAME validation: When you add the DNS record, select CNAME for the Record type. This can be done per site
or for your entire account. For more details, seeAutomatic Domain Validation for Imperva-Generated
Certificates.
• Meta tag validation: Imperva will automatically validate your domain by injecting an HTML meta tag in the
following scenarios:
• Onboarding a new site using the 1-step option. For more details, see Onboarding a Site – Web
Protection and CDN, Configure SSL for a new site.
• During the certificate renewal process. For more details, see Revalidate Your Imperva Certificate
If you did not complete SSL validation during the onboarding process and your site is already onboard with Imperva,
you can validate domain ownership using the email or DNS methods.
Once you have chosen a validation method and completed the validation steps, Imperva automatically adds your
domain to the Imperva certificate and provides DNS instructions. This is the final step in setting up your domain on
Imperva.
Note: If your site uses certificate pinning, it is not recommended to use an Imperva-generated certificate due to
occasional changes that are required on the Imperva side, such as certificate renewals, updates, and migrations. If
you choose to use certificate pinning, upload a custom certificate instead.
Imperva begins the renewal process 90 days before a certificate expires, which includes email notifications. The
exchange between the old certificate and the new one happens 3 days before the expiration date of the certificate.
Any SAN that is not verified before the exchange is dropped from the new certificate that is issued.
SNI values
When an Imperva proxy connects to the origin server, it sends the same SNI value that appears in the Host header
initially sent by the client. This value does not change when CNAME is used in a data center configuration, as detailed
in Load Balancing Settings. If you rewrite the Host header, the SNI value changes automatically. For details on how to
rewrite a Host header, see Create Rules, Rewrite Request Header.
You may choose to add your existing domain certificate to Imperva in addition to the Imperva-generated certificate.
This can be done by uploading the certificate and private keys to Imperva via the Cloud Security Console. For details,
see Upload a Custom Certificate for Your Website on Imperva.
It is important to note that these uploaded certificates are presented only to SNI-supporting clients. A list of SNI-
supporting clients can be found here: https://en.wikipedia.org/wiki/Server_Name_Indication.
The Imperva proxy first checks to see if a custom certificate was uploaded to the specific site. If one is not found, the
proxy looks at other sites in your account.
If the proxy identifies a certificate uploaded to another site in your account that has a SAN corresponding to the site in
question, then that custom certificate is used.
For example, suppose a custom certificate was not uploaded for your site support.example.com, but a certificate for
the wildcard domain *.example.com has been uploaded for another site in your account. The custom certificate for
*.example.com is used.
If you do not want the certificate for *.example.com used for your site, you need to upload a separate custom
certificate for the specific site.
If no matching certificate is located in any site in your account, the Imperva-generated certificate is used.
For websites onboarded to Imperva after October 20, 2021, the certificate selection method has changed. To optimize
the selection mechanism, the Imperva proxy now selects a certificate in this order:
3. A custom certificate from another website in any account with a SAN corresponding to the website in question.
All communication between visitors <--> Imperva (Connection A) is handled by the certificates stored in Imperva.
Communication between Imperva <--> your site (Connection B) is handled by the original domain certificate located
on your web server.
We employ the following advanced techniques, designed to speed up the process and minimize latency:
When traffic arrives at Imperva, can Imperva decrypt it and send me clear traffic?
No. To provide data security and meet PCI requirements, encryption is required during all legs of the journey.
Can our origin server send clear traffic to Imperva and have Imperva encrypt it before sending it back to visitors?
Do Imperva and your origin servers need to use the same TLS versions and cipher suites?
No. The connection between visitors <--> Imperva, and the connection between Imperva <--> your origin server are
two separate connections. Each segment can use a different TLS version and cipher suite.
PCI-DSS compliance requires disabling the use of TLS 1.0 as of July 1, 2018. To comply with this requirement, and due
to the known vulnerabilities in TLS 1.1, Imperva has defined TLS 1.2 as the default minimum supported version. This
also applies to the Imperva Cloud Security Console and the Imperva API.
Connectivity between a website’s origin server and the Imperva service is the responsibility of the Imperva customer.
Opting out
A client with an unsupported TLS version will not be able to establish a connection to Imperva. The client (a browser,
for example) may show the following SSL error message: ERR_SSL_VERSION_OR_CIPHER_MISMATCH, and will not be
able to access the site.
If you need to keep supporting TLS v1.0 and TLS v1.1, you can opt out and choose to enable support for all TLS
versions, on a per site basis. Opting out means that clients will be able to establish connections to your site using TLS
v1.0, v1.1, and v1.2. This is not recommended. To remain PCI compliant, do not enable this option.
Choosing to enable the option to support all TLS versions may require migration of your sites to the new Imperva
service network, which offers additional security options, customization, and visibility. As a result, you may be
required to update the following:
• Update of the A-record for your domain to point to the new IPs provided by Imperva.
• Revalidation of your Imperva-generated certificate/SAN for your opted-out sites: When possible, SSL certificates
currently in use will be moved automatically to the new platform. For certificates that cannot be moved
automatically, you will be required to revalidate ownership of your domain in order to issue new SSL
certificates. This typically requires that you add the relevant authorization string in a DNS TXT record to be
viewed by the CA. You will receive instructions on how to complete the revalidation.
Note: If you want to set TLS 1.1 as the minimum supported version for your site, contact Support.
To opt out of TLS 1.2 enforcement, enable support for all TLS versions:
1. Enable the Support All TLS Versions option for the account. For details, see Account Settings.
2. Enable the Support All TLS Versions option for each site that you want to support versions of TLS earlier than
1.2. For details, see Website General Settings.
1. Use the Modify Account Configuration operation in the Account Management API.
2. Use the Set support for all TLS versions operation in Site Management API.
Read More
Overview
After onboarding a website to Imperva and configuring SSL support, you can view certificate status details here. The
account SSL Certificates page provides status information for the certificates configured for all websites in your
account. After selecting a specific website, the SSL Certificates page displays only the status information for the
certificates configured for that website.
For more details on Imperva's SSL support for your websites, see Web Protection - SSL/TLS.
To view settings or configure SSL support after your site is onboarded, see Web Protection - General Settings.
Permissions
The Manage SSL Certificates permission is required to upload custom certificates and to change the validation
method.
By default, the account admin can perform these actions, and can add the required permission to roles assigned to
additional users.
Note: The legacy Manage custom certificates permission is still supported and enables users to upload custom
certificates.
SANs (Subject Alternative Names) are used in Imperva-generated certificates, which cover multiple domains. Each
SAN identifies a domain that is covered by the certificate. SANs that require user action are listed here.
You must complete the validation process in order for Imperva to approve your domain and include it in the Imperva-
generated SSL certificate.
Your domains are listed according to the validation method you chose when you started the process to configure SSL
support for the domain — either during website onboarding or after, through website settings.
Column Description
The value for the DNS record that is used for validation is
Record expires provided to Imperva by the certificate authority and
expires after 30 days.
Validate by email
Column Description
Last email sent Date of the last email sent to the specified email address.
The validity period of the SAN is typically 1 year, after
SANs expire
which you are required to revalidate domain ownership.
Certificates
This section lists the certificates configured for all websites in your account.
To add a custom certificate, click Add custom certificate and follow the onscreen instructions to upload your
certificate and private key. For details and requirements, see Upload a Custom Certificate for Your Website on
Imperva.
• Adding a custom certificate is available on the website-level page only. On the account-level, you can view,
update, or delete custom certificates.
• The option to use the existing certificate currently on your website has been deprecated.
Column Description
Column Description
Imperva-generated certificate:
Column Description
• RSA (Site)
• RSA (Account)
• ECC (Site)
SAN details
Expand a certificate row to view details on the SANs covered by the certificate.
Column Description
SAN The Subject Alternative Name (SAN).
SAN added The date that the SAN was added to the certificate.
The date that revalidation of your domain ownership will
Revalidation required
be required in order for Imperva to renew the certificate.
Column Description
SAN is approved by the CA, or if it requires you to
validate domain ownership.
1. Click the ellipsis and select Change validation method. The Change validation method window opens
with the current method selected and the values required to complete validation.
1. Click DNS.
2. Click the Record type dropdown and select one of the following:
◦ CNAME: This option is recommended to ensure automatic revalidation of the site in the future by
Imperva.
◦ TXT: This secondary option is for organizations that do not allow the use of a CNAME for site validation or
do not want Imperva to automatically manage this site's revalidation in the future.
3. Log into your DNS management console and open your DNS Zone file. If you are using a DNS management
service, log into it to make the change.
4. Set the Record type to match what you selected from the dropdown.
5. Copy the Host string into the DNS Record name field.
Note: The CNAME host string includes a prefix that defines your domain's delegation to Imperva. For
example: _delegate_validation.<domain>
7. In the Change validation method window, click Save. Imperva verifies that the value of the new record(s) has
been added to your DNS zone file. This may take a few minutes.
1. Click Email.
2. Select an email address from the drop-down menu where you want to receive the validation link. The drop-
down menu is populated with default emails for the domain (e.g. admin@, administrator@, etc.). If you don't
recognize any of the addresses or want to add emails to this list, see Adding Emails for Ownership Validation.
Note: You can test whether these email addresses are correct by clicking the Send a test email to all the
addresses link which sends test emails to all the listed addresses. This enables you to check whether you
receive these emails, thus indicating that the addresses are correct. The test emails sent in this manner do not
contain a validation link.
3. After you select an email, click Save. The validation email is sent to the selected address.
4. Open the email you receive and click on the validation link. After the domain is approved by the CA, Imperva
sends a confirmation email and updates the SAN status to Validated.
For instructions on using the SSL Certificates API, see SSL Certificates API Definition.
The definition file presents a full, formatted, and interactive version of the APIs that you can use to learn about the
APIs, or test them using your API ID and key. You can also download the definition file.
SSL Settings
View and manage SSL/TLS settings for all websites in your account.
Note:
The following permissions are required to view and edit SSL settings: View account SSL settings, Manage account
SSL settings. They are assigned automatically to the Administrator role. For details, see Manage Roles and
Permissions.
Overview
The SSL Settings page lets you view and manage general website configurations, Imperva certificates and the
automatic validation status of your domains.
General configuration
This section contains the general SSL configuration options for your account.
Cipher selection
This section contains the Cipher configuration options for your account.
Enable support for all TLS versions Enabling this option opens the TLS versions setting for
sites in your account. After you enable this option, enable
the Support All TLS Versions option for each site that
you want to support the earlier TLS versions. For details,
see Website General Settings.
For sites with the www prefix, adds the naked domain
SAN to the Imperva SSL certificate for newly created
WWW sites.
Note:
Once you prove ownership of your new SAN, the minimum amount of time needed to generate an Imperva certificate
for the newly added site is approximately 1 hour. Depending on the SAN’s age, this time could be significantly
extended.
For example, within the first 3 hours after site creation, Imperva monitors the SAN every 5 minutes, enabling us to
complete the validation process very quickly. If SAN validation is not completed during this initial period, the intervals
that Imperva monitors the SAN gradually increase, delaying the amount of time required to generate your Imperva
certificate.
Imperva then validates all new subdomains during onboarding, and continues to revalidate your ownership of these
domains when the Imperva-generated SSL certificate needs to be renewed.
To learn more about this feature, see Automatic Domain Validation for Imperva-Generated Certificates.
1. Enable the Allow CNAME validation for this account option to delegate the task of domain ownership
validation to Imperva.
3. For each domain that you add to the Domain delegation list below, copy its unique Record Name and CNAME
Value into the CNAME record in your DNS in order to complete the delegation process.
Imperva automatically validates domain ownership for domains on the Domain Delegation List that you successfully
configure.
Note: When you configure the CNAME for a SAN at the sub account level, the CNAME overrides any setting that is
configured for its parent domain at the account level. All configurations apply only to the subdomains within the same
sub account.
Column Description
Column Description
Date the domain was added to the domain delegation
Created
List.
Sub-account overview
The Sub-account overview lists the CNAME validation status of all your sub accounts in which automatic validation is
enabled. (It is not enabled automatically when enabled in the parent account.)
1. Hover over a row in the CNAME Validation Status table to display the Open icon at the end of the row.
2. Click the icon to open the sub account in a new tab. An SSL Settings page opens for the sub account and
displays all its domains in the Domain delegation list table.
Column Description
The definition file presents a full, formatted, and interactive version of the APIs that you can use to learn about the
APIs, or test them using your API ID and key. You can also download the definition file.
Note:
• Automatic validation can typically take from 30 minutes to 2 hours until completed.
Overview
Maintenance of domains can be a tedious and time-consuming task for site administrators, especially for enterprises
with multiple domains. Imperva enables you to automate this recurring requirement by allowing us to validate
domain ownership on your behalf.
Imperva automatically validates domain ownership of your domains and their subdomains that are subsequently
onboarded to Imperva. This includes:
When you configure a top-level domain for automatic validation, Imperva provides you with a unique CNAME value.
Once configured in your DNS, Imperva can automatically validate your domain ownership for the domain and its
subdomains, according to the same CNAME record. This allows for automatic domain validation in your accounts and
subaccounts that have enabled the feature.
For example, example1.com and example2.com each require a unique CNAME value. While the division1.com CNAME
record is in place in your DNS configuration, the SANs a.example1.com and *.a.example1.com will automatically be
validated by Imperva during onboarding and renewal because they inherit the CNAME value from their top-level
domain, example1.com.
Limitations
• This feature supports up to 5 levels of subdomains. For example, If you delegate example.com, Imperva can
validate a.b.c.d.e.example.com, but not a.b.c.d.e.f.example.com.
• This feature supports up to 3,000 domains per account. The addition of domains past this limit is blocked.
The process of automating domain validation for your account includes the following steps:
Enable the Automatic domain validation feature for your account or subaccount.
Add the list of domains you want to be automatically validated to your account's Domain delegation list.
For each domain that you delegate to Imperva, you are provided with unique Record Name and CNAME values.
Configure the CNAME record in your DNS with these values in order to complete the delegation process.
Note: To ensure seamless automatic revalidation of your domains for future certificate renewals, you must
maintain the relevant CNAME records within your DNS configuration.
• Enabling it in a parent account does not automatically enable it in the subaccounts. It must be enabled in each
subaccount that wants to use the feature.
• When enabled in the parent and also in a subaccount, automatic domain validation applies to domains defined
in either the parent account or the subaccount, according to the domain delegation lists.
• If enabled only in a subaccount and not in the parent account, automatic domain validation applies only to
domains defined in the subaccount, according to the subaccount's domain delegation list.
Configure automatic domain validation on the SSL Settings page for your account. For details, see SSL Settings.
API
The /v3/account/ssl-settings endpoint enables you to configure the settings for the account:
• Use the allowCNAMEValidation parameter to enable the automatic domain validation. This option is disabled
by default.
• allowedDomainsForCNAMEValidation param to define the list of domains that are delegated to Imperva for
domain validation.
For full details on using the API, see SSL Certificates API Definition.
You can set up automatic domain validation when onboarding a new website to Imperva, even if you have not
configured the feature at the account level.
When you add a website to your account using the Cloud Security Console's Onboarding wizard, you have the option
to add coverage for your site to an Imperva-generated SSL certificate.
To ensure automatic revalidation of the site in the future by Imperva, select the option to Validate ownership by
adding DNS records and select the CNAME record type.
Note: Configuring CNAME validation at the website level is not recommended for sites that are configured to add the
domain's wildcard SAN to the certificate if there are other sites in the account that also use the wildcard. In the event
that the website that was configured with the CNAME validation is removed, automatic validation will be removed for
all the related sites.
To ensure automatic domain validation of the site for future certificate renewals, change the validation method used
for the site to CNAME and update the domain's DNS record.
For details, see the Change validation method section here: Manage SSL Certificates.
Note: As of December 31, 2024 4096 bit SSL certificates will no longer be supported by Imperva Cloud WAF. As of
December 31, 2024, any attempt to upload a 4k certificate for your website will be blocked.
Action required: If you are currently using a 4k custom certificate, upload a different certificate at your earliest
convenience, or plan to do so the next time the certificate needs to be renewed. You can instead use one of the
following recommended options:
• ECC certificates: ECC certificates provide the same or greater level of security as RSA but with significantly
shorter key lengths. The efficiency of ECC allows for faster computation times, reduced computational power
requirements, and decreased bandwidth usage. Less data is passed to the client during the TLS handshake,
making ECC an ideal choice for resource-constrained devices like IoT devices and mobile phones. For more
details, see Improving Cybersecurity: Different Certifications Explained.
• ECC 384-bit key - security strength equivalent to an RSA 7680-bit key. (Contact Imperva Support for
approval.)
• ECC 256-bit key - security strength equivalent to an RSA 3072-bit key. (Supported by default.)
• 2k RSA certificates: Industry standard and approved safe for use by the U.S. National Security Agency (NIST).
• 2k RSA Imperva-generated certificates: A complimentary offering, which includes the option to delegate
certificate renewal to Imperva, saving you time and effort.
Overview
Your certificate is presented to SNI-supporting clients only. Adding your domain to an Imperva SAN certificate is
required to handle non-SNI supporting clients, even if you are uploading your own existing certificate. A list of SNI-
supporting clients can be found here: https://en.wikipedia.org/wiki/Server_Name_Indication.
Requirements
• You can upload a maximum of one RSA certificate and one ECC certificate per website. For additional
requirements for ECC certificates, see ECC Certificate Support.
• Supported file formats: PEM, CRT, P7B, DER, CER, PFX, P12, CERT, KEY, CA-BUNDLE, BUNDLE, and PRIV
• The certificate must contain the full chain – the origin server certificate, followed by all intermediate CA
certificates, and then the root CA certificate. For details, see Extracting the Full Chain Certificate Using Qualys
SSL Labs.
• The certificate must include the SAN for the website’s domain.
• Each time you upload a custom certificate to Imperva for your website, the Enable HTTP/2 setting on the
Website Delivery Settings page is reset according to account-level HTTP/2 default settings, located in Account >
Account Management > Account Settings. For details, see Delivery Settings and Account Settings.
• Untrusted certificates with Subject Alternative Names (SANs) that do not cover the domain of your onboarded
website are not supported.
For example, for site a.b.com, you can use an untrusted certificate that includes only the SAN a.b.com,
www.a.b.com, or both. Wildcard SANs are not allowed.
If the certificate does not contain SANs under the extension node, then the Common Name (CN) specified in the
certificate must also be equal to the full or www domain of the onboarded site.
Required permissions
The Manage SSL Certificates permission is required to upload, replace, and delete custom certificates for your
website.
(The legacy Manage custom certificates permission is also still supported at this time.)
This permission is granted to the Account Admin user by default. The Account Admin or any user with Manage users/
Manage user roles permissions can assign this permission to other account users as needed.
If the proxy identifies a certificate uploaded to another site in your account that has a SAN corresponding to the site in
question, then that custom certificate is used.
For example, suppose a custom certificate was not uploaded for your site support.example.com, but a certificate for
the wildcard domain *.example.com has been uploaded for another site in your account. The custom certificate for
*.example.com is used.
If you do not want the certificate for *.example.com used for your site, you need to upload a separate custom
certificate for the specific site.
If no matching certificate is located in any site in your account, the Imperva-generated certificate is used.
For websites onboarded to Imperva after October 20, 2021, the certificate selection method has changed. To optimize
the selection mechanism, the Imperva proxy now selects a certificate in this order:
3. A custom certificate from another website in any account with a SAN corresponding to the website in question.
Upload API
To upload a custom certificate via the Imperva API, use the https://api.imperva.com/sites/{extSiteId}/
customCertificate endpoint. For details, see Cloud WAF v2 API Definition.
Read More
Overview
You can upload your own ECC certificate to Imperva so it can be presented to your website visitors.
ECC certificates have a smaller key size than RSA certificates, so less data is passed to the client during the
TLS handshake. This results in faster page load times, as well as offering better support for mobile devices.
ECC certificates provide a security level comparable to or surpassing that of an RSA 2048 certificate.
Guidelines:
• Connecting clients must support ECC or the TLS handshake cannot be completed with an ECC certificate. If you
want to also support non-ECC supporting clients, upload an RSA certificate as well.
• By default, Imperva supports the prime256v1 (secp256r1) Elliptic Curve Digital Signature Algorithm (ECDSA)
only.
• Imperva presents your ECC certificate to SNI-supporting clients only. Adding your domain to an Imperva SAN
certificate is required to handle non-SNI supporting clients.
On the SSL Certificates page for a specific website, click Add custom certificate and follow the onscreen instructions.
Remove the security overhead of managing and sending private keys over the web. Imperva manages the private key
for you, according to our security standards.
Step Description
Overview
When you onboard a secure website to Imperva, there are two alternatives for installing SSL certificates on the
Imperva proxy servers. You can opt to have Imperva generate a new certificate for your site, or you can upload your
own custom certificate.
If you choose to use your own certificate, but regulatory requirements demand that your certificate's private key be
hosted in an HSM, you can upload own certificate without the private key while maintaining the private key in a 3rd
party cloud HSM service.
This topic describes how to upload your custom certificate to Imperva without the private key, and store your key in a
cloud HSM service instead.
Fortanix Data Security Manager (DSM) SaaS is the HSM service currently supported for this integration.
Perform the following steps to set up the Fortanix side of the integration. Refer to the Fortanix documentation for
more details: Fortanix Data Security Manager with Imperva Cloud WAF.
Note: In the event of a Fortanix outage, reliance on a single region can leave the protected site without SSL support. In
addition, if you have end-users around the world, it is recommended to enable the service across multiple regions to
optimize performance. Therefore, at least 2 regions are recommended for reliability of service.
2. Create a group for purposes of this Imperva integration. The group will contain a collection of security objects,
such as your certificate and key, and enable you to assign access policies to these objects.
3. Create an application for Imperva Cloud WAF. The application will be used to authenticate Imperva to Fortanix
Data Security manager using an API key.
4. Create a security object and import your cryptographic key, using Base64 format.
• The URI. This is the location of your assets in the HSM service. In this case, it's the URI (host name) of the
Fortanix region as it appears in the security object. For example, api.amer.smartkey.io.
• The key ID. This is the UUID of the Fortanix security object.
• The API key. This is the REST API authentication key from the Fortanix application you created.
There are three API operations available for managing your certificate.
• Upload certificate: Upload your certificate and HSM credentials to Imperva. The certificate must use Base64
encoding.
• Test connectivity: When you upload your certificate and HSM credentials, Imperva automatically checks the
connection. If you later make changes in your Fortanix configuration, it is recommended to run this API call to
check that Imperva can still successfully connect to your Fortanix account.
For full details on the API for HSM Support, see Cloud WAF v2 API Definition.
As with all Imperva APIs, you also need to provide your Imperva API key and ID as headers in the request. For more
details, see Authentication.
In the event that you want to remove the certificate from Imperva, you can also delete it there.
Latency check
Check the latest HSM latency between a given Imperva data center (PoP) and a specific Fortanix region.
This check is available via the Imperva API, using the v3/certificates/hsm/latency endpoint.
See also:
• Authentication
For more info on the Imperva-generated certificate, see Web Protection - SSL/TLS.
Overview
Typically, when your site's Imperva-generated certificate needs to be renewed, the process is completed
automatically by Imperva. In some instances, you will receive an email notification from Imperva requiring you to
revalidate ownership of your domain.
It is critical to review the required action and deadline as specified in the email and take prompt action. If your
websites are not revalidated before their certificate's deadline, they will be removed from the new certificate and lose
SSL support, making them unreachable over SSL.
Note: Website validation using a CNAME lets you automate the revalidation process of your site:
• For any site with a certificate that will soon expire, update its DNS record with a CNAME Record type. For more
details, see Manage SSL Certificates > Change validation method.
• Configure a site's parent domain with a CNAME at the account level. For more details, see Automatic Domain
Validation for Imperva-Generated Certificates.
Email notification
When you are required to revalidate ownership of your domain, Imperva sends you an email that details the actions
required and a deadline. For example, if you need to add DNS records, it lists the values that must be added to your
DNS zone file.
Subject lines of the mail: "Domain revalidation required" or "Domain revalidation deadline".
Note: Imperva also sends a "SAN Approved" email for each SAN that it automatically validates (i.e., CNAME, metatag).
For more details, see Automatic Domain Validation for Imperva-Generated Certificates.
1. On the SSL Certificates page, Certificates section, a domain that is set to expire has SAN status: Pending user
action.
For more information on domains pending ownership validation and changing validation methods, see Manage SSL
Certificates.
After website ownership has been validated for all domains on a certificate or its deadline has arrived, Imperva starts
the process of revalidating the SSL certificate for the site via the CA. Imperva send you an email when the process is
complete.
Important to know
• Your site's DNS record must contain the subdomain
"_validation-contactemail"
. This subdomain is only used to store the validation email addresses. Generally, the CA has already created this
subdomain and added common admin emails (e.g., admin@, administrator@, etc.).
• Each email address is added as a separate DNS TXT entry using the
"_validation-contactemail"
subdomain. Imperva can only use email addresses listed on the subdomain to validate site ownership.
• All subdomains registered to the domain are validated with the email address you use to validate the domain or
revalidate an Imperva-generated certificate. You don't have to specify an email address for every subdomain.
• Remove the DNS record an email address to remove its ability to validate site ownership.
The example below shows the correct format for the fictional domain altostrat.com and a user named Kiran. Be
sure to replace your domain and the email address for the values in the example.
Note: This feature is currently supported for new sites onboarded after March 11, 2024. Sites created prior to that date
will undergo automatic migration at a later time.
Overview
When a new website is onboarded to Imperva protection, it is assigned a default TLS configuration profile. The
configuration profile includes HSTS options, supported TLS versions, and supported cipher suites.
By default, Imperva supports a specific set of cipher suites for secure communication over HTTPS, according to the
TLS version used for the connection.
Using the Website TLS Configuration API, you can customize the configuration profile.
For full details on the Website TLS Configuration API, see Website Management API Definition.
• HSTS configuration
• Default
• Enhanced (stricter)
• Custom
If you choose to customize the list of supported cipher suites, select the Custom profile , and then configure the
supported TLS versions and ciphers.
Example:
},
"inboundTlsSettings": {
"configurationProfile": "CUSTOM",
"tlsConfiguration": [
{
"tlsVersion": "TLS_1_3",
"ciphersSupport": [
"TLS_AES_128_GCM_SHA256",
"TLS_CHACHA20_POLY1305_SHA256"
]
}
]
}
For details on customizing the TLS versions and cipher suites used by Imperva for connectivity between your website
visitors and the Imperva service, see Customize Website TLS Configuration.
Note: Imperva has defined TLS 1.2 as the default minimum supported version. If you need to support earlier versions,
you must enable the Support All TLS Versions option. For details, see the TLS version support section in Web
Protection - SSL/TLS.
For earlier TLS versions, the ciphers listed below with ECDSA in the name are relevant only to ECC certificates. All
other ciphers are relevant only to RSA certificates.
Default
TLS_AES_128_GCM_SHA256 TLS_AES_128_GCM_SHA256
Enhanced Security
Default
TLS_CHACHA20_POLY1305_SHA256 TLS_CHACHA20_POLY1305_SHA256
Enhanced Security
Default
TLS_AES_256_GCM_SHA384 TLS_AES_256_GCM_SHA384
Enhanced Security
TLS 1.2
Default
TLS_ECDHE_RSA_WITH_AES_128_GC
ECDHE-RSA-AES128-GCM-SHA256
M_SHA256
Enhanced Security
Default
TLS_ECDHE_ECDSA_WITH_AES_128_
ECDHE-ECDSA-AES128-GCM-SHA256
GCM_SHA256
Enhanced Security
Default
TLS_ECDHE_RSA_WITH_AES_256_GC
ECDHE-RSA-AES256-GCM-SHA384
M_SHA384
Enhanced Security
Default
TLS_ECDHE_ECDSA_WITH_AES_256_
ECDHE-ECDSA-AES256-GCM-SHA384
GCM_SHA384
Enhanced Security
Default
TLS_ECDHE_RSA_WITH_CHACHA20_
ECDHE-RSA-CHACHA20-POLY1305
POLY1305_SHA256
Enhanced Security
Default
TLS_ECDHE_ECDSA_WITH_CHACHA2
ECDHE-ECDSA-CHACHA20-POLY1305
0_POLY1305_SHA256
Enhanced Security
TLS_ECDHE_RSA_WITH_AES_128_CB
ECDHE-RSA-AES128-SHA256 Default
C_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CB
ECDHE-RSA-AES256-SHA384 Default
C_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CB
ECDHE-RSA-AES128-SHA Default
C_SHA
TLS_ECDHE_RSA_WITH_AES_256_CB
ECDHE-RSA-AES256-SHA Default
C_SHA
TLS_RSA_WITH_AES_128_GCM_SHA
AES128-GCM-SHA256 Default
256
TLS_RSA_WITH_AES_256_GCM_SHA
AES256-GCM-SHA384 Default
384
TLS_RSA_WITH_AES_128_CBC_SHA2
AES128-SHA256 Default
56
TLS_RSA_WITH_AES_256_CBC_SHA2
AES256-SHA256 Default
56
TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA Default
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA Default
If the origin server chooses an earlier TLS version, the proxy will accept it.
When TLS version 1.2 or earlier is chosen by the origin server, it can use ciphers from the TLS 1.2 list below that are
available in the TLS version chosen.
TLS 1.3
TLS 1.2
See also:
CAA Compliance
As of September 2017, the CA/Browser Forum Baseline Requirements require all Certificate Authorities (CAs) to check
for Certificate Authority Authorization (CAA) records before issuing or renewing certificates.
A CAA record enables domain owners to specify on their DNS which CAs are authorized to issue certificates for their
domain.
CAA records are not mandatory, but they are recommended. CAA use helps you limit the CAs that can issue certificates
for your domain, and can prevent unauthorized issuance of certificates.
• no CAA records
• a CAA record that names the specific CA
If your DNS zone file currently contains CAA records, but does not contain a record for the CA you are requesting a
certificate from, that CA cannot issue or renew a certificate for your domain.
CAA Checking
When you onboard a new SSL site or enable SSL for an existing site, Imperva checks for CAA compliance to ensure the
successful issuing of certificates. This applies to Imperva-generated certificates (including multi-domain SAN
certificates) only.
Before configuring SSL for an existing site: 1. If your domain is using CAA, make sure you have
the CAA records required by Imperva.
1. Log in to your DNS management console and access your DNS zone file.
2. Do one of the following:
◦ Remove any CAA records of other CAs that are using the issue or issuewild property.
◦ Add the following records:
• CAA 0 issue “globalsign.com”
• CAA 0 issuewild "globalsign.com"
Mutual Transport Layer Security (mTLS), an extension of the TLS protocol, utilizes client certificates to establish secure
communication channels between two systems. Each system is presents its certificate to the other to verify its own
identify.
The purpose of mTLS is to use a client certificate to allow the server to verify the authenticity and authorization level
of the client, as opposed to a server certificate where the client verifies the authenticity of the server.
Imperva supports client certificates as follows. You can opt to take advantage of either or both of the options.
Between your end users and Imperva: If your site needs to support client certificates, you can upload your CA
certificate to Imperva and configure your websites to use it. The Client-to-Imperva (mTLS) feature supports mutual
authentication between your end users and Imperva. For configuration instructions, see Client-to-Imperva Client
Certificate mTLS Support.
Between Imperva and your origin servers: You can also enable mutual authentication between Imperva and your
origin servers. For instructions on configuring Imperva-to-Origin (mTLS) support, see Imperva-to-Origin Client
Certificate mTLS Support.
Client certificates provide an additional layer of security. They are used to verify the client's identify to a server,
ensuring that communication occurs over a secure and trusted connection.
The Client to Imperva (mTLS) feature supports mutual authentication between your end users and Imperva.
Note:
• Client certificates are supported for websites configured in Imperva for SSL and using a custom certificate.
• Client certificates are supported for SNI clients only. We do not support client certificates for non-SNI clients.
• Client certificates are supported per domain, not per URL.
To learn more about Imperva client certificate support, see Client Certificate Support.
Overview
The growing distribution of mobile apps and electronic IDs means you may need to implement a higher level of
protection, such as two-factor authentication.
In addition, IoT services may rely on embedded client certificates on end devices to validate device authenticity.
Configuring client certificate support for a website includes the following steps:
Note:
• When enabling Client to Imperva mTLS, it can take up to 10 minutes for changes to take effect.
• When you first assign a certificate to a website, the client certificate is not required by default, and traffic is still
permitted to access the site without presenting the client certificate. To require the client certificate for the
TLS handshake, see Configure client certificate support settings .
Guidelines:
• The certificate must be in PEM format. Supported file extensions include .pem, .crt, and .cer.
• If more than one certificate is used for signing, they should be concatenated.
• We recommend that the file you upload contains only one certificate.
• You can add up to 1000 CA certificates to your account.
• You can assign up to 120 certificates per site.
Permissions:
By default, the account admin user can manage client CA certificates for the account and websites in the account.
Other users can be granted the following permissions as required:
The Client to Imperva (mTLS) Certificates pages are displayed only to users with the appropriate permissions.
Account-level. The account-level Client to Imperva (mTLS) Certificates page enables you to upload your client
CA certificates and then assign them to websites in your account.
Website-level. The Client to Imperva (mTLS) Certificates page located within settings for a specific website enables
you to view the certificates assigned to the website, or assign a certificate from the account to the website.
1. On the top menu bar, click Application and then select a website.
For accounts with sub accounts: You can upload a client CA certificates to the parent account only. You can then
assign the certificate to any website in the account or in any of the account's sub accounts.
To upload a certificate, open the account-level Client to Imperva (mTLS) Certificates page and click Upload New.
Option Description
Uploaded file The file name of the uploaded certificate file.
Name Give a descriptive name to the certificate.
• On the account-level Client to Imperva (mTLS) Certificates page, click More > Edit for a certificate and modify
the list of assigned websites.
• On the website-level Client to Imperva (mTLS) Certificates page, click Assign and select a certificate from the
drop-down.
Option Description
Option Description
When enabled, the contents specified under Header
value are sent to the origin server in the header specified
under Header name. By default, set to false.
• The account-level Client to Imperva (mTLS) Certificates page displays all client CA certificates uploaded to your
account.
• The website-level Client to Imperva (mTLS) Certificates page displays all client CA certificates assigned to the
website.
Column Description
If client authentication by the website is also required, Imperva can send the authentication information to your
origin server in a request header. For details, see Configure client certificate support settings above.
If you need to pass additional client parameters to the origin server, and your service plan includes Delivery Rules, you
can create delivery rules and use the following variables. If not, the Support team can implement it for you.
For more details on using these variables in delivery rules, see Create Rules.
After you receive the client certificate information, you can convert it into a certificate object.
Upload a CRL
If client certificate support is enabled for your site, you can upload a Certificate Revocation List (CRL) file to verify
whether certificates are valid and trustworthy.
Note: To learn more about client certificate support, see Client Certificate Support.
Guidelines
• The CRL file must be in PEM format, using Base64 encoding.
• The CRL file cannot be larger than 1MB.
• You can upload multiple CRLs per site.
• You cannot upload multiple CRL files to a site that include the same issuer.
• To replace an existing CRL, delete the CRL file and upload a new one.
The Certificate Manager API definition file provides a full, formatted, and interactive version of the Certificate Manager
API that you can use to learn about the API, or test the APIs using with your API ID and key. You can also download the
definition file.
CRL APIs
If client certificate support is enabled for your site, you can use the API to upload a Certificate Revocation List (CRL)
file to verify whether certificates are valid and trustworthy.
These APIs enable you to manage the Client to Imperva (mTLS) feature, which supports mutual authentication
between your end users and Imperva.
The definition file presents a full, formatted, and interactive version of the Certificate Manager APIs that you can use
to learn about the APIs, or test them using your API ID and key. You can also download the definition file.
See also:
Manage and upload a Certificate Revocation List (CRL) file to verify whether certificates are valid and trustworthy.
Access
1. APIKey KeyParamName:x-API-Id KeyInQuery:false KeyInHeader:true
2. APIKey KeyParamName:x-API-Key KeyInQuery:false KeyInHeader:true
Methods
Models
Table of Contents
CRL
•
post /sites/{siteId}/CRL
•
put /sites/{siteId}/CRL/{crlId}
•
get /sites/{siteId}/CRL
•
delete /sites/{siteId}/CRL/{crlId}
ClientCertificates
•
post /v2/accounts/{accountId}/client-certificates
•
post /v2/sites/{siteId}/client-certificates/{certId}
•
delete /v2/sites/{siteId}/client-certificates/{certId}
•
delete /v2/accounts/{accountId}/client-certificates/{certId}
•
put /v2/sites/{siteId}/configuration/client-certificates
•
get /v2/sites/{siteId}/client-certificates
•
get /v2/sites/{siteId}/configuration/client-certificates
•
get /v2/accounts/{accountId}/client-certificates
•
get /v2/accounts/{accountId}/client-certificates/{certId}
•
post /v2/sites/{siteId}/configuration/client-certificates
CRL
Up
post /sites/{siteId}/CRL
Add CRL to site (addCRL)
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
Consumes
This API call consumes the following media types via the Content-Type request header:
• multipart/form-data
Form parameters
crl_file (optional)
Form Parameter — format: binary
name (optional)
Form Parameter —
Return type
CRLDetails
Example data
Content-Type: application/json
{
"name" : "CRL Name",
"siteId" : 1,
"id" : 1,
"creationDate" : "2023-07-18"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success CRLDetails
406
Invalid CRL file name, file limit exceeded, failed to read CRL file, unauthorized siteId
500
server error
Up
put /sites/{siteId}/CRL/{crlId}
Update existing CRL on site (fullUpdateCRL)
Replaces the CRL currently uploaded to the website
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
crlId (required)
Path Parameter — The Imperva ID for the CRL. format: int64
Consumes
This API call consumes the following media types via the Content-Type request header:
• multipart/form-data
Form parameters
crl_file (optional)
Form Parameter — format: binary
name (optional)
Form Parameter —
Return type
CRLDetails
Example data
Content-Type: application/json
{
"name" : "CRL Name",
"siteId" : 1,
"id" : 1,
"creationDate" : "2023-07-18"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success CRLDetails
406
Invalid CRL file name, file limit exceeded, failed to read CRL file, unauthorized siteId
500
server error
Up
get /sites/{siteId}/CRL
List site CRLs (listCRLs)
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
Return type
CRLDetails
Example data
Content-Type: application/json
{
"name" : "CRL Name",
"siteId" : 1,
"id" : 1,
"creationDate" : "2023-07-18"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success CRLDetails
406
unauthorized siteId
500
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
crlId (required)
Path Parameter — The Imperva ID for the CRL. format: int64
Responses
200
success
406
unauthorized siteId
500
server error
ClientCertificates
Up
post /v2/accounts/{accountId}/client-certificates
Add client CA certificate to account (addClientCACert)
Path parameters
accountId (required)
Path Parameter — The Imperva ID for the account. format: int64
Consumes
This API call consumes the following media types via the Content-Type request header:
• multipart/form-data
Form parameters
ca_file (optional)
Form Parameter — format: byte
name (optional)
Form Parameter —
Return type
ClientCACertificateDetails
Example data
Content-Type: application/json
{
"serialNumber" : "FB:4B:BD:4B:1B:7D:7C:CF",
"name" : "Cert name",
"id" : 1,
"validFrom" : "2000-01-23T04:56:07.000+00:00",
"creationDate" : "2023-07-18",
"issuer" : "[email protected], CN=My-company, OU=Support, O=My-co
mpany, ST=California, C=US",
"hash" : "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"validTo" : "2000-01-23T04:56:07.000+00:00"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success ClientCACertificateDetails
401
unauthorized account
406
bad request
500
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
certId (required)
Path Parameter — The Imperva ID assigned to an uploaded certificate. <br>Run GET method to locate the certificate
ID. format: int64
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success
401
unauthorized site
406
bad request
500
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
certId (required)
Path Parameter — The Imperva ID assigned to an uploaded certificate. <br>Run GET method to locate the certificate
ID. format: int64
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success
401
unauthorized site
406
bad request
500
Path parameters
accountId (required)
Path Parameter — The Imperva ID for the account. format: int64
certId (required)
Path Parameter — The Imperva ID assigned to an uploaded certificate. <br>Run GET method to locate the certificate
ID. format: int64
Responses
200
success
401
unauthorized account
406
bad request
500
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
Consumes
This API call consumes the following media types via the Content-Type request header:
• application/json
Request body
body ClientCACertificateSiteConfiguration (required)
Body Parameter — configuration to update
Return type
ClientCACertificateSiteConfiguration
Example data
Content-Type: application/json
{
"isDisableSessionResumption" : true,
"headerName" : "Full-Cert",
"hosts" : [ "imperva.com", "imprevaservices.com" ],
"isPortsException" : false,
"headerValue" : "FULL_CERT",
"ports" : [ 80, 9000 ],
"mandatory" : true,
"isHostsException" : false,
"forwardToOrigin" : true,
"fingerprints" : "F009B2EABECCBE9BFBE23B8C57A684650B8564A9"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success ClientCACertificateSiteConfiguration
401
unauthorized account
406
invalid Json
500
server error
Up
get /v2/sites/{siteId}/client-certificates
List all client CA certificates assigned to site (getAllCertsForSite)
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
Return type
ClientCACertificateDetails
Example data
Content-Type: application/json
{
"serialNumber" : "FB:4B:BD:4B:1B:7D:7C:CF",
"name" : "Cert name",
"id" : 1,
"validFrom" : "2000-01-23T04:56:07.000+00:00",
"creationDate" : "2023-07-18",
"issuer" : "[email protected], CN=My-company, OU=Support, O=My-co
mpany, ST=California, C=US",
"hash" : "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"validTo" : "2000-01-23T04:56:07.000+00:00"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success ClientCACertificateDetails
401
unauthorized site
406
bad request
Up
get /v2/sites/{siteId}/configuration/client-certificates
Get client CA certificate configuration for site (getSiteConfiguration)
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
Return type
ClientCACertificateSiteConfiguration
Example data
Content-Type: application/json
{
"isDisableSessionResumption" : true,
"headerName" : "Full-Cert",
"hosts" : [ "imperva.com", "imprevaservices.com" ],
"isPortsException" : false,
"headerValue" : "FULL_CERT",
"ports" : [ 80, 9000 ],
"mandatory" : true,
"isHostsException" : false,
"forwardToOrigin" : true,
"fingerprints" : "F009B2EABECCBE9BFBE23B8C57A684650B8564A9"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success ClientCACertificateSiteConfiguration
401
unauthorized account
Up
get /v2/accounts/{accountId}/client-certificates
List client CA certificates in account (listClientCACertsByAccount)
Path parameters
accountId (required)
Path Parameter — The Imperva ID for the account. format: int64
Return type
array[ClientCACertificateDetails]
Example data
Content-Type: application/json
[ {
"serialNumber" : "FB:4B:BD:4B:1B:7D:7C:CF",
"name" : "Cert name",
"id" : 1,
"validFrom" : "2000-01-23T04:56:07.000+00:00",
"creationDate" : "2023-07-18",
"issuer" : "[email protected], CN=My-company, OU=Support, O=My-co
mpany, ST=California, C=US",
"hash" : "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"validTo" : "2000-01-23T04:56:07.000+00:00"
}, {
"serialNumber" : "FB:4B:BD:4B:1B:7D:7C:CF",
"name" : "Cert name",
"id" : 1,
"validFrom" : "2000-01-23T04:56:07.000+00:00",
"creationDate" : "2023-07-18",
"issuer" : "[email protected], CN=My-company, OU=Support, O=My-co
mpany, ST=California, C=US",
"hash" : "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"validTo" : "2000-01-23T04:56:07.000+00:00"
} ]
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success
401
unauthorized account
403
forbidden access
Up
get /v2/accounts/{accountId}/client-certificates/{certId}
Get client CA certificate information including assigned sites (listSitesByCert)
Path parameters
accountId (required)
Path Parameter — The Imperva ID for the account. format: int64
certId (required)
Path Parameter — The Imperva ID assigned to an uploaded certificate. <br>Run GET method to locate the certificate
ID. format: int64
Return type
ClientCACertificateDetails
Example data
Content-Type: application/json
{
"serialNumber" : "FB:4B:BD:4B:1B:7D:7C:CF",
"name" : "Cert name",
"id" : 1,
"validFrom" : "2000-01-23T04:56:07.000+00:00",
"creationDate" : "2023-07-18",
"issuer" : "[email protected], CN=My-company, OU=Support, O=My-co
mpany, ST=California, C=US",
"hash" : "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"validTo" : "2000-01-23T04:56:07.000+00:00"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success ClientCACertificateDetails
401
unauthorized account
406
bad request
Up
post /v2/sites/{siteId}/configuration/client-certificates
Modify the client CA certificate configuration (partial update) (partialUpdateSiteConfiguration)
Path parameters
siteId (required)
Path Parameter — The Imperva ID for the website. format: int64
Consumes
This API call consumes the following media types via the Content-Type request header:
• application/json
Request body
body ClientCACertificateSiteConfiguration (required)
Body Parameter — configuration sections to update
Return type
ClientCACertificateSiteConfiguration
Example data
Content-Type: application/json
{
"isDisableSessionResumption" : true,
"headerName" : "Full-Cert",
"hosts" : [ "imperva.com", "imprevaservices.com" ],
"isPortsException" : false,
"headerValue" : "FULL_CERT",
"ports" : [ 80, 9000 ],
"mandatory" : true,
"isHostsException" : false,
"forwardToOrigin" : true,
"fingerprints" : "F009B2EABECCBE9BFBE23B8C57A684650B8564A9"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
success ClientCACertificateSiteConfiguration
401
unauthorized account
406
invalid Json
500
server error
Models
Methods
Table of Contents
1.
CRLDetails
2.
ClientCACertificateDetails
3.
ClientCACertificateSiteConfiguration
4.
body
5.
body_1
6.
body_2
CRLDetails
Up
id (optional)
Long format: int64
example: 1
name (optional)
String
example: CRL Name
creationDate (optional)
String
example: 2023-07-18
siteId (optional)
Long format: int64
example: 1
ClientCACertificateDetails
Up
id (optional)
Long format: int64
example: 1
name (optional)
String
example: Cert name
serialNumber (optional)
String
example: FB:4B:BD:4B:1B:7D:7C:CF
issuer (optional)
String
example: [email protected], CN=My-company, OU=Support, O=My-company, ST=California, C=US
validFrom (optional)
Date format: date-time
validTo (optional)
Date format: date-time
creationDate (optional)
String
example: 2023-07-18
hash (optional)
String
example: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
ClientCACertificateSiteConfiguration
Up
mandatory (optional)
Boolean When set to true, the end user is required to present the client certificate in order to access the site.By
default, set to false.
example: true
ports (optional)
array[Long] The ports on which client certificate authentication is supported. If left empty, client certificates are
supported on all ports. format: int64
example: [80,9000]
isPortsException (optional)
Boolean When set to true, client certificates are not supported on the ports listed in the Ports field ('blacklisted'). By
default, set to false.
example: false
hosts (optional)
array[String] The hosts on which client certificate authentication is supported. If left empty, client certificates are
supported on all hosts.
example: ["imperva.com","imprevaservices.com"]
isHostsException (optional)
Boolean When set to true, client certificates are not supported on the hosts listed in the Hosts field ('blacklisted').By
default, set to false.
example: false
fingerprints (optional)
array[String] Permitted client certificate fingerprints. If left empty, all fingerprints are permitted.
example: F009B2EABECCBE9BFBE23B8C57A684650B8564A9
forwardToOrigin (optional)
Boolean When set to true, the contents specified in headerValue are sent to the origin server in the header specified
by headerName. By default, set to false.
example: true
headerName (optional)
String The name of the header to send header content in. By default, the header name is 'clientCertificateInfo'.
example: Full-Cert
headerValue (optional)
String The content to send in the header specified by headerName. One of the following: FULL_CERT (for full
certificate in Base64) COMMON_NAME (for certificate's common name (CN)) FINGERPRINT (for the certificate
fingerprints in SHA1) SERIAL_NUMBER (for the certificate's serial number)
Enum:
FULL_CERT
COMMON_NAME
FINGERPRINT
SERIAL_NUMBER
example: FULL_CERT
isDisableSessionResumption (optional)
Boolean
body
Up
ca_file
byte[] Upload a client certificate for your website.<br>The certificate must be in PEM format.<br>Supported file
extensions include .pem, .crt and .cer. format: byte
name (optional)
String CA certificate file name
body_1
Up
crl_file (optional)
byte[] Upload a Certificate Revocation List (CRL) file for your website. <br>The CRL file must be in PEM format, using
Base64 encoding and cannot be larger than 1MB. <br>Replaces a CRL currently uploaded to the website. format:
binary
name (optional)
String CRL name
body_2
Up
crl_file (optional)
byte[] Upload a Certificate Revocation List (CRL) file for your website. <br>The CRL file must be in PEM format, using
Base64 encoding and cannot be larger than 1MB. <br>Replaces a CRL currently uploaded to the website. format:
binary
name (optional)
Client certificates provide an additional layer of security. They are used to verify the client's identity to a server,
ensuring that communication occurs over a secure and trusted connection.
Note:
• This feature is currently offered on the basis of Controlled Availability. For more information, contact your
account manager or Imperva Support.
• Automated email notifications regarding certificate expiration are not sent for this feature. This enhancement is
planned for a later date.
To learn more about Imperva client certificate support, see Client Certificate Support.
Overview
Mutual TLS (or mTLS) is a method for two-way authentication.
In TLS communication, the server has a TLS certificate, enabling the connecting client to verify the identity of the
server. With mTLS, the connecting client also presents a certificate, enabling the server to verify the client's identity as
well.
By uploading your client certificate to Imperva, the Imperva proxy can present it to your origin server during the TLS
handshake, enabling you to verify that the connecting client is indeed an Imperva proxy.
Once both sides have authenticated their identities to the other, secure communication between Imperva and your
origin server begins.
Permissions
By default, the account admin user can manage client certificates for the account and for websites in the account.
The Account Admin or any user with Manage users/Manage user roles permissions can assign the following
permission to other account users as needed.
Process overview
2. Upload the certificate to Imperva and configure your websites to use it.
3. Configure your origin server to require and validate the client certificate.
• For RSA certificates, the public key must be 2048 bit or less.
• For ECC certificates, the public key must be 256 bit or less.
• The certificate should be issued by a private or a public (trusted) certificate authority (CA) and cannot be self-
signed. If a public CA is being used, then it is your responsibility to block unwanted certificates on your own
origin server.
• Supported file formats: PEM, CRT, P7B, DER, CER, PFX, P12, CERT, KEY, CA-BUNDLE, BUNDLE, and PRIV
To upload a certificate, open the Imperva to Origin (mTLS) Certificates page and click Add.
3. Assign to websites (optional - you can do this at a later time). For details, see Assign the certificate to websites
below.
This can be done during the certificate upload process, or at a later time.
You can assign a single certificate to any or all of the websites in your account, or upload multiple certificates.
Each website can have only one Imperva to Origin mTLS client certificate assigned to it.
1. On the Imperva to Origin (mTLS) certificates page, locate the certificate that you want to assign.
2. Click the ellipsis and select Assign to websites. For each website, the following details are listed:
3. Select the websites you want to assign this certificate to and click Apply.
Configuration varies between different web servers. Consult the server's documentation for specific instructions.
# SSL configuration
listen 443 ssl;
ssl_certificate /serverCert.pem; #path to your server certificate
ssl_certificate_key /serverPrivkey.pem; #path to your server certificate’s private key
ssl_client_certificate /myCaCert.pem; #path to your client CA certificate in PEM format.
ssl_verify_client on; #always verify client certificate
Column Description
The name you assign to the certificate, and the unique
Name (ID)
identifier assigned by Imperva.
Issued to The domain that the certificate applies to.
EMAILADDRESS
L: Locality
C: Country Name
Column Description
Deleting the certificate may cause outages for
applications that still use it. Before deleting the
certificate, we strongly advise you to ensure that
these applications are not using it.
Audit trail
The following events are logged in the audit trail for your account:
Access
1. APIKey KeyParamName:x-API-Id KeyInQuery:false KeyInHeader:true
Methods
Models
Table of Contents
HSMCertificates
•
get /v3/certificates/hsm/latency
SSLCertificates
•
put /v3/certificates/{certificateId}/sans/{sanId}/validationMethod
•
get /v3/certificates
•
get /v3/instructions
SSLSettings
•
post /v3/account/ssl-settings/delegation/domain/{domain}
•
delete /v3/account/ssl-settings
•
get /v3/account/ssl-settings
•
patch /v3/account/ssl-settings
•
delete /v3/account/ssl-settings/delegation/domain/{domainId}
•
post /v3/account/ssl-settings
•
post /v3/account/ssl-settings/delegation/domain/{domainId}/status
HSMCertificates
Up
get /v3/certificates/hsm/latency
Get HSM latency (getLatency)
Get the latest HSM latency between a given Imperva data center (PoP) and a specific Fortanix region.<br/>This
operation returns the time it takes for Imperva to get the private key from Fortanix.It does not include the session
creation time.
Query parameters
pop (required)
Query Parameter — The code of the Imperva data center (PoP) to check latency for.<br/>For the full list of PoPs and
codes, see <a href='https://docs.imperva.com/bundle/cloud-application-security/page/more/pops.htm'>Imperva
Data Centers</a>.
hsmHostName (required)
Query Parameter — The URI (host name) of the Fortanix region.<br/>Possible values: amer, uk, eu, apac, au in the
required format, e.g. api.amer.smartkey.io
Return type
HsmLatencyDetailsResponse
Example data
Content-Type: application/json
{
"data" : [ {
"requestTime" : 1677144366,
"hsmHostName" : "api.amer.smartkey.io",
"latency" : 146
}, {
"requestTime" : 1677144366,
"hsmHostName" : "api.amer.smartkey.io",
"latency" : 146
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
504
SSLCertificates
Up
put /v3/certificates/{certificateId}/sans/{sanId}/validationMethod
Change SAN validation method (changeSanValidationMethod)
Changes the SAN validation method and value used for certificate revalidation.
Path parameters
certificateId (required)
Path Parameter — The Imperva ID assigned to the certificate. Use the GET /v3/certificates API call to retrieve the IDs of
certificates in your account. format: int64
sanId (required)
Path Parameter — The Imperva ID assigned to the SAN. Use the GET /v3/certificates API call to retrieve the SAN IDs of
certificates in your account. format: int64
Consumes
This API call consumes the following media types via the Content-Type request header:
• application/json
Request body
body ChangeValidationMethodRequest (required)
Body Parameter —
Return type
ChangeValidationMethodExternalResponse
Example data
Content-Type: application/json
{
"data" : [ {
"validationMethod" : "DNS",
"recordType" : "TXT",
"domain" : "example.imperva.com",
"verificationCodeExpirationDate" : 1633380421000,
"validationEmail" : "[email protected]",
"lastNotificationDate" : 1633180421000,
"expirationDate" : 1633180421000,
"verificationCode" : "globalsign-domain-verification=1234"
}, {
"validationMethod" : "DNS",
"recordType" : "TXT",
"domain" : "example.imperva.com",
"verificationCodeExpirationDate" : 1633380421000,
"validationEmail" : "[email protected]",
"lastNotificationDate" : 1633180421000,
"expirationDate" : 1633180421000,
"verificationCode" : "globalsign-domain-verification=1234"
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Query parameters
extSiteId (optional)
Query Parameter — The Imperva ID of the onboarded website. Retrieves certificate details for a specific website. If not
specified, this API retrieves details of all certificates in the account. format: int64
certType (optional)
Query Parameter — The type of certificate to provide details for
Return type
Certificate
Example data
Content-Type: application/json
{
"level" : "SITE",
"sans" : [ {
"statusDate" : 1,
"sanValue" : "sanValue",
"validationMethod" : "validationMethod",
"autoValidation" : true,
"cnameValidationValue" : "cnameValidationValue",
"approverFqdn" : "approverFqdn",
"sanId" : 0,
"numSitesCovered" : 5,
"validationEmail" : "validationEmail",
"expirationDate" : 6,
"status" : "status",
"verificationCode" : "verificationCode"
}, {
"statusDate" : 1,
"sanValue" : "sanValue",
"validationMethod" : "validationMethod",
"autoValidation" : true,
"cnameValidationValue" : "cnameValidationValue",
"approverFqdn" : "approverFqdn",
"sanId" : 0,
"numSitesCovered" : 5,
"validationEmail" : "validationEmail",
"expirationDate" : 6,
"status" : "status",
"verificationCode" : "verificationCode"
} ],
"renewalCertOrderId" : "ATLAS_47_3483659225",
"siteName" : "Site Name",
"type" : "ATLAS",
"customCertificateDetails" : {
"inputHash" : "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
"hsmType" : "FORTANIX",
"serialNumber" : "FB:4B:BD:4B:1B:7D:7C:CF",
"hsm" : true,
"hasMismatchSite" : true,
"fingerprint" : "SHA1 Fingerprint=FE:AB:F3:B4:93:0C:56:CF:4B:EC:E0:29:1C:C5:8
A:9E:47:78:4E:A9"
},
"name" : "ATLAS_47_3483659225",
"inRenewal" : true,
"originCertOrderId" : "ATLAS_47_3483659225",
"id" : 2674,
"extSiteId" : 856963,
"authType" : "RSA",
"status" : "IN_PROCESS",
"expirationDate" : 1633180421000
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Query parameters
extSiteId (optional)
Query Parameter — The Imperva ID of the onboarded website. format: int64
validationMethod (optional)
Query Parameter — The methods that can be used to validate ownership of the domain.
certificateType (optional)
Query Parameter — The type that can be used to get san instructions.
Return type
SanInstructionsDto
Example data
Content-Type: application/json
{
"relatedSansDetails" : 1633180421000,
"validationMethod" : "DNS",
"recordType" : "TXT",
"domain" : "example.imperva.com",
"verificationCodeExpirationDate" : 1633180421000,
"validationEmail" : "[email protected]",
"lastNotificationDate" : 1633180421000,
"expirationDate" : 1633180421000,
"verificationCode" : "856963"
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
401
Unauthorized APIErrors
500
SSLSettings
Up
post /v3/account/ssl-settings/delegation/domain/{domain}
Add domain to the SSL validation delegation settings (addDomainToSSLValidationDelegationSettings)
Add domain to the SSL validation delegation settings of your account. Delegating a domain enables Imperva to
perform domain ownership validation on your behalf during website onboarding and certificate renewal.
Path parameters
domain (required)
Path Parameter —
Return type
AccountSSLSettingsResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
}, {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Return type
AccountSSLSettingsResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
}, {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Return type
AccountSSLSettingsResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
}, {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Consumes
This API call consumes the following media types via the Content-Type request header:
• application/json
Request body
body AccountSettingsDto (required)
Body Parameter —
Return type
AccountSSLSettingsResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
}, {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Path parameters
domainId (required)
Path Parameter — domainId can be getting from this api (GET /v3/account/ssl-settings) format: int64
Return type
AccountSSLSettingsResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
}, {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Consumes
This API call consumes the following media types via the Content-Type request header:
• application/json
Request body
body AccountSettingsDto (required)
Body Parameter —
Return type
AccountSSLSettingsResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
}, {
"allowSupportOldTLSVersions" : true,
"enableHSTSForNewSites" : true,
"impervaCertificate" : {
"useWildCardSanInsteadOfFQDN" : true,
"addNakedDomainSanForWWWSites" : true,
"delegation" : {
"allowedDomainsForCNAMEValidation" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ],
"allowCNAMEValidation" : true
}
}
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Path parameters
domainId (required)
Path Parameter — domainId can be getting from this api (GET /v3/account/ssl-settings) format: int64
Return type
AllowDelegationDomainWithInheritanceResponseDto
Example data
Content-Type: application/json
{
"data" : [ {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
}, {
"lastStatusCheck" : 1663446207139,
"cnameRecordValue" : "_abc.a1234.validation.imperva.com",
"cnameRecordHost" : "_delegate_validation.example.com",
"inherited" : false,
"name" : "example.com",
"id" : 123,
"statusSince" : 1663446207139,
"creationDate" : 1663446207139,
"status" : "CONFIGURED"
} ]
}
Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
400
500
Models
Methods
Table of Contents
1.
APIError
2.
APIErrors
3.
AccountDtoSSLDelegationSettingsDto
4.
AccountSSLSettingsResponseDto
5.
AccountSettingsDto
6.
AllowDelegationDomainWithInheritanceResponseDto
7.
AllowDomainDelegationWithInheritance
8.
Certificate
9.
CertificateSanDetails
10.
ChangeValidationMethodDTO
11.
ChangeValidationMethodExternalResponse
12.
ChangeValidationMethodRequest
13.
CustomCertificateDetails
14.
HsmLatencyDetailsResponse
15.
HsmLatencyDto
16.
ImpervaGeneratedCertificateSettingsDto
17.
RelatedSansDetails
18.
SanInstructionsDto
APIError
Up
status (optional)
Integer format: int32
id (optional)
String
code (optional)
String
source (optional)
map[String, Object]
title (optional)
String
detail (optional)
String
APIErrors
Up
errors (optional)
array[APIError]
AccountDtoSSLDelegationSettingsDto
Up
allowedDomainsForCNAMEValidation (optional)
array[AllowDomainDelegationWithInheritance]
allowCNAMEValidation (optional)
Boolean Enable Imperva to automatically perform domain ownership validation on your behalf for domains in the
allowedDomainsForCNAMEValidation list.
example: true
AccountSSLSettingsResponseDto
Up
data (optional)
array[AccountSettingsDto]
AccountSettingsDto
Up
impervaCertificate (optional)
ImpervaGeneratedCertificateSettingsDto
allowSupportOldTLSVersions (optional)
Boolean When true, sites under the account or sub-accounts can allow support of old TLS versions traffic. This can be
configured only on the parent account level.
example: true
enableHSTSForNewSites (optional)
Boolean When true, enables HSTS support for newly created websites.
example: true
AllowDelegationDomainWithInheritanceResponseDto
Up
data (optional)
array[AllowDomainDelegationWithInheritance]
AllowDomainDelegationWithInheritance
Up
The list of domains delegated to Imperva for purposes of domain ownership validation. Subdomains of the domains
in the list are also automatically validated by Imperva. Wildcards are not allowed.
id (optional)
Long The domain id. format: int64
example: 123
name (optional)
String The domain name.
example: example.com
creationDate (optional)
Long The domain creation date. format: int64
example: 1663446207139
status (optional)
String The domain status. Possible values: CONFIGURED, NOT_CONFIGURED
example: CONFIGURED
statusSince (optional)
Long The date the domain status was last modified. format: int64
example: 1663446207139
lastStatusCheck (optional)
Long The date the domain status was last verified. format: int64
example: 1663446207139
inherited (optional)
Boolean CNAME validation is automatically inherited from a parent domain that is delegated to Imperva. When
domain delegation configured (true) for a specific subdomain, its CNAME value overrides the current setting of the
parent domain.
example: false
cnameRecordValue (optional)
String The CNAME record value to use to configure this domain for delegation.
example: _abc.a1234.validation.imperva.com
cnameRecordHost (optional)
String The CNAME record host to use.
example: _delegate_validation.example.com
Certificate
Up
id (optional)
Long The Imperva ID of the certificate. format: int64
example: 2674
name (optional)
String For an Imperva-generated certificate, indicates the certificate name and the ID of the Imperva request to the CA.
example: ATLAS_47_3483659225
status (optional)
String Certificate status
example: IN_PROCESS
type (optional)
String Certificate type
Enum:
ATLAS
CUSTOM_CERT
MANUAL
example: ATLAS
expirationDate (optional)
Long Certificate expiration date format: int64
example: 1633180421000
inRenewal (optional)
Boolean Is certificate under renewal process
example: true
renewalCertOrderId (optional)
String The order ID of the Imperva request to the CA for a new certificate that will replace an expiring certificate. This
certificate will replace the certificate specified by originCertOrderId.
example: ATLAS_47_3483659225
originCertOrderId (optional)
String The order ID of the Imperva request to the CA for a certificate that is set to expire in the near future and must be
renewed. This certificate will be replaced by the certificate specified by renewalCertOrderId.
example: ATLAS_47_3483659225
sans (optional)
CertificateSanDetails
Up
List of Subject Alternative Names found on the certificate
sanId (optional)
Long format: int64
sanValue (optional)
String
validationMethod (optional)
String
expirationDate (optional)
Long format: int64
status (optional)
String
statusDate (optional)
Long format: int64
numSitesCovered (optional)
Integer format: int32
verificationCode (optional)
String
cnameValidationValue (optional)
String
autoValidation (optional)
Boolean
approverFqdn (optional)
String
validationEmail (optional)
String
ChangeValidationMethodDTO
Up
Validation instructions.
domain (optional)
String Validation domain
example: example.imperva.com
expirationDate (optional)
Long SAN expiration date format: int64
example: 1633180421000
validationEmail (optional)
String Validation email
example: [email protected]
validationMethod (optional)
String SAN Validation method
Enum:
EMAIL
DNS
CNAME
METATAG
URL
HTTP
NONE
example: DNS
recordType (optional)
String validation record type
Enum:
TXT
CNAME
A
NONE
example: TXT
verificationCode (optional)
String SAN Verification code
example: globalsign-domain-verification=1234
verificationCodeExpirationDate (optional)
Long Verification code expiration date format: int64
example: 1633380421000
lastNotificationDate (optional)
Long Last date an email was sent format: int64
example: 1633180421000
ChangeValidationMethodExternalResponse
Up
data (optional)
array[ChangeValidationMethodDTO] Validation instructions.
ChangeValidationMethodRequest
Up
validationMethod
String SAN Validation method
Enum:
DNS
EMAIL
CNAME
METATAG
example: EMAIL
validationEmail (optional)
String Validation email. Required only when the EMAIL validation method is used.
example: [email protected]
CustomCertificateDetails
Up
hsmType (optional)
String The name of the HSM provider
example: FORTANIX
hasMismatchSite (optional)
Boolean Return true if domain is covered by the certificate
example: true
inputHash (optional)
String Internal use for terraform
example: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
fingerprint (optional)
String The certificate fingerprint
example: SHA1 Fingerprint=FE:AB:F3:B4:93:0C:56:CF:4B:EC:E0:29:1C:C5:8A:9E:47:78:4E:A9
serialNumber (optional)
String The certificate serialNumber
example: FB:4B:BD:4B:1B:7D:7C:CF
hsm (optional)
Boolean
HsmLatencyDetailsResponse
Up
data (optional)
array[HsmLatencyDto] HSM latency response.
HsmLatencyDto
Up
HSM latency response.
requestTime (optional)
Long The time the latency request was recorded.<br/> Unix epoch time, in milliseconds. format: int64
example: 1677144366
latency (optional)
Long The last latency in the pop format: int64
example: 146
hsmHostName (optional)
String The URI (host name) of the Fortanix region.<br/>Possible values: amer, uk, eu, apac, au in the required format,
e.g. api.amer.smartkey.io
example: api.amer.smartkey.io
ImpervaGeneratedCertificateSettingsDto
Up
delegation (optional)
AccountDtoSSLDelegationSettingsDto
useWildCardSanInsteadOfFQDN (optional)
Boolean Adds the wildcard SAN to the Imperva SSL certificate instead of the full domain SAN. The value you assign is
used as the default option when onboarding new websites.
example: true
addNakedDomainSanForWWWSites (optional)
Boolean For sites with the www prefix, adds the naked domain SAN to the Imperva SSL certificate. The value you
assign is used as the default option when onboarding new websites.
example: true
RelatedSansDetails
Up
List of related SANs using the same domain for validation
sanId (optional)
Long format: int64
sanValue (optional)
String
expirationDate (optional)
Long format: int64
SanInstructionsDto
Up
domain (optional)
String Domain to validate
example: example.imperva.com
expirationDate (optional)
Long SAN expiration date format: int64
example: 1633180421000
validationEmail (optional)
String Validation email
example: [email protected]
validationMethod (optional)
String Validation method of the SAN
Enum:
EMAIL
DNS
CNAME
METATAG
URL
HTTP
NONE
example: DNS
recordType (optional)
String Record type for the validation
Enum:
TXT
CNAME
A
NONE
example: TXT
verificationCode (optional)
String Verification code of the SAN
example: 856963
verificationCodeExpirationDate (optional)
Long Verification code expiration date format: int64
example: 1633180421000
lastNotificationDate (optional)
Long Last date an email was sent format: int64
example: 1633180421000
relatedSansDetails (optional)
array[RelatedSansDetails] List of related SANs using the same domain for validation
example: 1633180421000