0% found this document useful (0 votes)
106 views98 pages

SSL Certificates Cloud - Application - and - Network - Security - Web - Protection - SSL - Tls - 2024-06-04

Uploaded by

vijay konduru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
106 views98 pages

SSL Certificates Cloud - Application - and - Network - Security - Web - Protection - SSL - Tls - 2024-06-04

Uploaded by

vijay konduru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 98

Cloud Application and Network Security

Cloud Application and Network Security

Cloud Application and Network Security 1


Contents

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

Cloud Application and Network Security 2


Cloud Application and Network Security

Web Protection - SSL/TLS


This topic describes how Imperva handles secure communication.

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

• Custom certificate (optional)

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.

Cloud Application and Network Security 3


Cloud Application and Network Security

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.

GlobalSign Atlas Certificate Authority (CA)

Imperva-generated certificates are issued by GlobalSign.

• Certificates expire 6 months after creation.

• SANs expire 12 months after validation.

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.

Custom certificate (optional)

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.

Which certificate does Imperva use?

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.

Cloud Application and Network Security 4


Cloud Application and Network Security

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:

1. The website's custom certificate.

2. The Imperva-generated certificate.

3. A custom certificate from another website in any account with a SAN corresponding to the website in question.

The SSL process


HTTPS traffic arrives at Imperva, where Imperva terminates the SSL connection. It decrypts the traffic, analyzes it, and
filters out malicious visitors and requests. The next step for legitimate requests is for Imperva to return a response to
the visitor from the cache, or forward the request on to the origin server if necessary. Imperva encrypts the traffic at
this point before sending it on.

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.

Does Imperva add latency to SSL termination?

We employ the following advanced techniques, designed to speed up the process and minimize latency:

A normal SSL handshake requires 2 round trips (4


packets). Session resumption enables the client and the
server to complete an SSL handshake for connections
after the first connection (2nd, 3rd, etc) in one round trip,
Session resumption
by reusing some of the work done when the first
connection was established.

Imperva supports both session identifiers and session


tickets for session resumption. Session tickets are used if

Cloud Application and Network Security 5


Cloud Application and Network Security

supported by the client. Otherwise, session identifiers


are used.

When establishing SSL connections, clients need to verify


the certificate presented by the server. One of the checks
the client makes is to ensure the certificate was not
revoked by its CA. In order to do that, the client needs to
OCSP stapling contact the CA, which slows down the connection
process. OCSP allows the server to check the revocation
status of the certificate and send it to the client as part of
the connection, so the client doesn't have to contact the
CA itself.
HTTP/2 enables a client to send multiple simultaneous
requests over a single SSL connection. The result is that
HTTP/2
the HTTP/2 enabled clients do not need to open as many
connections as HTTP/1.x clients.
Imperva servers are optimized to run encryption related
Optimized hardware workloads by offloading some of the encryption
workload to hardware.

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?

No, for the same reason.

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.

TLS version support


TLS 1.3, 1.2, 1.1, and 1.0 are supported for connectivity between clients (visitors) and the Imperva service. TLS 1.2 is
the minimum supported version, by default.

PCI-DSS v3.2 compliance

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.

Cloud Application and Network Security 6


Cloud Application and Network Security

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:

From the Imperva Cloud Security Console:

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.

Using the API:

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.

For details, see Cloud Application Security v1/v3 API Definition.

Supported cipher suites


For the full list of cipher suites supported by Imperva, see Supported Cipher Suites.

Read More

• Website General Settings


• Customize Website TLS Configuration

Last updated: 2024-04-21

Cloud Application and Network Security 7


Cloud Application and Network Security

Manage SSL Certificates


View certificate details and status for all websites in your account or for a specific website, or upload a custom
certificate for a specific website.

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 View SSL Certificates permission is required to view the page.

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.

Open the SSL Certificates page


To view all SSL certificates in your account:

1. Log in to your account in the Imperva Cloud Security Console.


2. On the top menu bar, click Application.
3. On the sidebar, click SSL/TLS > SSL Certificates.

To view the SSL certificates for a specific website:

1. Complete steps 1 & 2 above.


2. On the sidebar, click Websites and click a website name.
3. On the sidebar, click SSL/TLS > SSL Certificates.

Domains pending ownership validation


This section lists all the domains in your account with SANs that require validation of domain ownership.

Cloud Application and Network Security 8


Cloud Application and Network Security

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.

Validate by adding DNS records

Column Description

The domain requiring validation of ownership.

Expand the domain name column to view the SANs


covered by the domain.
Domain name
Note: When the SAN validation type is CNAME, the
following prefix is added to the domain name:
_delegate_validation.example.com.

The type of DNS record used for validating domain


Type
ownership: CNAME or TXT.

Depending on the specified record type, add this value as


a CNAME or TXT record to your DNS configuration to
validate ownership of the domain.
Value
Tip: Click the copy button to copy the value string.

Imperva then verifies that the record has been added to


your DNS zone file. This may take a few minutes.

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.

The validity period of the SAN is typically 1 year, after


SANs expire
which you are required to revalidate domain ownership.

Cloud Application and Network Security 9


Cloud Application and Network Security

Validate by email

Column Description

The domain requiring validation of ownership.


Domain name
Expand the domain name column to view the SANs
covered by the domain.

The email address you selected during website


Email address onboarding or when configuring SSL support. An email
with a validation link was sent to this email address.

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

For Imperva-generated certificates: Indicates the


certificate name and the ID of the Imperva request to the
CA. Click the down arrow to expand the row and view all
the SANs and websites covered by this certificate. For
more information, see SAN details.
Name (Order ID)
For Custom certificate: Indicates a certificate that you
have uploaded to Imperva for your website. Click the
Custom certificate link to open the website settings to
view or manage the certificate configuration.

Cloud Application and Network Security 10


Cloud Application and Network Security

Column Description

Custom certificate: The website for which this certificate


Website
was issued.

Imperva-generated certificate:

• Active: The certificate is in use for the specified


website.

• In progress: The current certificate in use for the


website is set to expire in the near future and must
be renewed. This certificate is being prepared to
replace the old one.

• Under renewal: This certificate is in use but is set to


expire in the near future. Imperva has started the
renewal process.

Status Custom certificate:

• Active: The certificate is in use for the specified


website.

• Will expire soon: The certificate is set to expire and


you need to upload a new one to maintain SSL
support. This status is activated 60 days before the
expiration date.

• Site mismatch: The certificate does not match the


website's domain.

• Expired: For secure communication, remove this


certificate and replace it with a valid certificate.

SANs (#) The number of SANs covered by this certificate.

The certificate's expiration date.


Expiration Date
Imperva-generated certificates are valid for 6 months.

The type of certificate:


Certificate Type
• RSA [HSM] (Site)

Cloud Application and Network Security 11


Cloud Application and Network Security

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).

The number of websites covered by this SAN.

Click the number to view the website names and their


Imperva IDs.
Websites covered
A wildcard SAN such as *.example.com may cover several
subdomains of example.com, such as dev.example.com
and docs.example.com.

The methods that can be used to validate ownership of


the domain. Validation may be required by Imperva and
the CA when providing or renewing an Imperva-
Validation method generated certificate.

Note: When the Automatic tag appears, no user action is


required and the SAN status is In process.

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.

• Validated: The SAN is covered by the certificate.

SAN status • In process: You have onboarded a new site and


requested SSL support, or started the SSL support
configuration process after onboarding. Imperva is
processing the request and checking to see if the

Cloud Application and Network Security 12


Cloud Application and Network Security

Column Description
SAN is approved by the CA, or if it requires you to
validate domain ownership.

• Not active: There was a problem generating the


TXT record for domain validation. This status
generally resolves quickly and is moved to Pending
user action. In rare cases, it can stay for longer,
indicating an internal Imperva issue or a problem
with the CA. If the status does not update, contact
Imperva Support.

• Pending user action: You are required to validate


ownership of the domain. Click the icon at the end
of the row for instructions.

Note: The Pending user action status is displayed


until Imperva receives confirmation from the CA
that the validation process was completed
successfully.

Click the ellipsis to display more options.

Note: The ellipsis appears for users with


permission to view the Change validation method
More options
window. The icon appears for users without
permission.

Instructions: displays the values required to complete


the current validation method (email, DNS), as described
in Domains pending ownership validation.

Change validation method: opens a window to switch


between email and DNS options (TXT or CNAME).

Change validation method


When a specific SAN's status is Pending user action or In process you can change its validation method.

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.

2. Toggle the tabs to select a different option: DNS or Email.

Cloud Application and Network Security 13


Cloud Application and Network Security

Validate your website ownership by adding a DNS record

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.

Note: Field names may vary between different DNS providers.

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>

6. Copy the Value string into the DNS Value field.

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.

Validating your website ownership by email

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.

SSL Certificates API


Use the SSL Certificates API to:

Cloud Application and Network Security 14


Cloud Application and Network Security

• Get certificate details

• Get the status of your account

• Change a SAN's validation method

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.

Last updated: 2024-05-26

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.

Open the SSL Settings page


1. Log in to your account in the Imperva Cloud Security Console.
2. On the top menu bar, click Application.
3. On the sidebar, click SSL/TLS > Settings.

General configuration
This section contains the general SSL configuration options for your account.

Enables HTTP Strict Transport Security for all new SSL


sites added after this setting is enabled. HSTS instructs
Set HSTS as the default for newly created SSL sites visitors to communicate with a domain only over a
secured connection (HTTPS). For more details, see Web
Protection - General Settings.

Cloud Application and Network Security 15


Cloud Application and Network Security

Cipher selection
This section contains the Cipher configuration options for your account.

Note: This TLS option is only visible to admin users with


account level permissions.

In compliance with PCI-DSS requirements to disable the


use of TLS 1.0, and due to known vulnerabilities in TLS
1.1, Imperva has defined TLS 1.2 as the default minimum
supported version for connectivity between clients
(visitors) and Imperva.

This option enables you to set support for TLS versions


earlier than 1.2 on a per site basis.

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.

To remain PCI-compliant, do not enable this option. For


more details, see Web Protection - SSL/TLS.

Note: You cannot disable this option if it is enabled for


any of the account's sites. First disable the Support all
TLS versions option for each site in the site's General
Settings page.

Imperva generated certificate


This section contains the configuration options for your account that are needed to generate an Imperva certificate.

Adds the wildcard SAN to the Imperva SSL certificate


instead of the full domain SAN.
Use wildcard SAN in Imperva’s certificate for newly
Example: For www.example.com, the wildcard SAN is
created SSL sites
*.example.com and the full domain SAN is
www.example.com.

Options include: True or False.

Cloud Application and Network Security 16


Cloud Application and Network Security

Using a wildcard SAN enables you to add subdomains,


such as sub.example.com, without the need for a
certificate change and revalidation.

Note: Typically, when your site's Imperva-generated


certificate needs to be renewed, the process is
completed automatically by Imperva.

• If you add CNAME validation at the account level


for a domain (using Automatic domain validation),
the wildcard SAN will be revalidated automatically.

• If not using CNAME validation at the account level,


the wildcard SAN will be revalidated automatically
only if the domain (e.g. example.com) is also
protected by Imperva. Otherwise, you will receive
an email notification from Imperva requiring you
to revalidate ownership of your domain.

For sites with the www prefix, adds the naked domain
SAN to the Imperva SSL certificate for newly created
WWW sites.

Example: For www.example.com, the SAN example.com


is added to the certificate in addition to the wildcard or
full domain SAN.

Note: Typically, when your site's Imperva-generated


certificate needs to be renewed, the process is
completed automatically by Imperva.
Include naked domain SAN
• If you add CNAME validation at the account level
for a domain (using Automatic domain validation),
the naked domain SAN will be revalidated
automatically.

• If not using CNAME validation at the account level,


the naked domain SAN will be revalidated
automatically only if the domain (e.g.
example.com) is also protected by Imperva.
Otherwise, you will receive an email notification
from Imperva requiring you to revalidate
ownership of your domain.

Note:

Cloud Application and Network Security 17


Cloud Application and Network Security

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.

Automatic domain validation


Delegate to Imperva the ability to prove ownership of the domains in your account using CNAME validation.

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.

Enable automatic domain validation

1. Enable the Allow CNAME validation for this account option to delegate the task of domain ownership
validation to Imperva.

2. Add domains to the Domain delegation list.

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.

Domain delegation list

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

List of the domains configured for automatic domain


validation.

Note: If CNAME validation is enabled for both an account


Domain
and a subaccount, the subaccount "inherits" the
domains from the parent account. The domain
delegation list of the subaccount displays all account
level domains indicated by the Inherited label.

Cloud Application and Network Security 18


Cloud Application and Network Security

Column Description
Date the domain was added to the domain delegation
Created
List.

Indicates if the domain is correctly configured in your


Status DNS for Imperva to automatically manage its ownership
validation: Configured or Not Configured.

Copy this unique Record name into the CNAME record in


Record Name
your DNS.

Copy this unique CNAME value into the CNAME record in


your DNS.
CNAME Value
Note: Each unique CNAME value can only be used to
validate a single top-level domain.

Click the ellipsis to display more options:

Instructions: Displays the Record name and


More options CNAME value that must be added to the CNAME record
for the domain in your DNS.

Check status: Click to verify if the domain has been


properly configured in your DNS.

Delete: Click to remove the domain from the domain


delegation 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.)

Note: This section is displayed only in a parent account.

To view and manage the domains in a sub 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.

Cloud Application and Network Security 19


Cloud Application and Network Security

Column Description

Name List of all the sub accounts.

The Allow CNAME validation for this account setting for


CNAME Validation
the sub account: Enabled or Disabled.

Number of domains in a sub account's Domain


delegation list that are successfully configured.
Domains Fully Configured
Note: No value (–) is displayed when CNAME validation is
disabled for the sub account.

Number of domains in a sub account's Domain


Delegation List that are not yet configured.
Domains Not Configured
Note: No value (–) is displayed when CNAME validation is
disabled for the sub account.

SSL Settings API


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.

Last updated: 2024-04-21

Automatic Domain Validation for Imperva-Generated


Certificates
Delegate the task of domain ownership validation to Imperva to save time and effort during site onboarding and
certificate renewal.

Note:

• This feature applies to Imperva-generated SSL certificates only.

• Automatic validation can typically take from 30 minutes to 2 hours until completed.

Cloud Application and Network Security 20


Cloud Application and Network Security

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:

• issuing new Imperva-generated SSL certificates when onboarding new sites

• managing domain revalidation as required for certificate renewal

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.

Configuring automatic domain validation

The process of automating domain validation for your account includes the following steps:

1. Enable the feature.

Enable the Automatic domain validation feature for your account or subaccount.

2. Configure the domain list.

Add the list of domains you want to be automatically validated to your account's Domain delegation list.

3. Update your DNS configuration.

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.

Cloud Application and Network Security 21


Cloud Application and Network Security

Accounts and subaccounts

Automatic domain validation works as follows in accounts with subaccounts:

• You can enable automatic domain validation in a parent account or in a subaccount.

• 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


Configure the settings for your account in the Cloud Security Console, or using the Imperva API.

Cloud Security Console

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.

The /v3/account/ssl-settings/delegation/domain/{domain} endpoint enables you to add a domain to "allowed


domains" list.

For full details on using the API, see SSL Certificates API Definition.

Configure automatic domain validation for specific sites


When onboarding a new site

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.

Cloud Application and Network Security 22


Cloud Application and Network Security

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.

For details, see Onboarding a Site – Web Protection and CDN.

For future revalidation of an existing site

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.

Last updated: 2024-04-21

Upload a Custom Certificate for Your Website on Imperva


Upload your own SSL certificate to Imperva so it can be presented to your web site visitors.

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.

Imperva supports the following:

• 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.

Cloud Application and Network Security 23


Cloud Application and Network Security

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's public key must be less than 4096 bits.

• 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.

Which certificate does Imperva use?


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.

Cloud Application and Network Security 24


Cloud Application and Network Security

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:

1. The website's custom certificate.

2. The Imperva-generated certificate.

3. A custom certificate from another website in any account with a SAN corresponding to the website in question.

How to upload a custom certificate to Imperva


Open the SSL Certificates page for a specific website:

1. Log in to your account in the Imperva Cloud Security Console.


2. On the top menu bar, click Application.
3. On the sidebar, click Websites and click a website name.
4. On the sidebar, click SSL/TLS > SSL Certificates.
5. In the Certificates section, click Add custom certificate and follow the onscreen instructions to upload your
certificate and private key (if required).

For more details, see Manage SSL Certificates.

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

• ECC Certificate Support


• Onboarding a Site – Web Protection and CDN
• Web Protection - General Settings

Cloud Application and Network Security 25


Cloud Application and Network Security

Last updated: 2024-05-26

ECC Certificate Support


In addition to RSA certificates, Imperva Cloud WAF now supports ECC certificates.

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.

Upload an ECC certificate


Upload your certificate and private key to Imperva.

On the SSL Certificates page for a specific website, click Add custom certificate and follow the onscreen instructions.

For more details and requirements, see:

• Upload a Custom Certificate for Your Website on Imperva.

• Web Protection - SSL/TLS

Last updated: 2024-04-21

Upload a Certificate without a Private Key


This topic explains the process of uploading a custom certificate for your site to Imperva, without providing a private
key.

Cloud Application and Network Security 26


Cloud Application and Network Security

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

Generate a certificate signing request using the Create


New CSR operation of the Imperva Cloud Application
1. Generate a CSR
Security API. For details. see the Site Management API
here: Cloud Application Security v1/v3 API Definition.

Use the CSR content from the API response to create a


CSR file, and send it to the CA. The CA sends a certificate
without a private key back to you.
2. Send CSR file to CA
Note: The API output contains a "\n" newline character.
Before sending the CSR file to the CA, remove the "\n" or
replace it with a newline character that works for your
system.

Upload the certificate to Imperva using one of the


following:

• UI: The Imperva Cloud Security Console


SSL Certificates page. For details, see Upload a
Custom Certificate for Your Website on Imperva.
• API: The Upload custom certificate operation. For
details, see the Site Management API here: Cloud
Application Security v1/v3 API Definition.
3. Upload certificate to Imperva
Note:

• When a new custom certificate is uploaded, any


previous CSR file and the related private key are
removed and cannot be used again.

• If you delete a custom certificate that was


generated with a CSR, the CSR and the private key
are also deleted.

Last updated: 2024-04-21

Cloud Application and Network Security 27


Cloud Application and Network Security

Upload a Custom Certificate with HSM Support


Upload a custom certificate for your website to Imperva, while maintaining your private key in an external key
management and encryption service.

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.

Configure the HSM


Before uploading your certificate to Imperva, you need to have a Fortanix account.

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.

1. Sign up for Fortanix Data Security Manager and create an account.

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.

HSM details required by Imperva


When configuring the integration on the Imperva side, you need to provide Imperva with the following details from
the Fortanix Data Security Manager:

• 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.

Cloud Application and Network Security 28


Cloud Application and Network Security

• 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.

Upload your certificate and HSM details


To configure the integration, upload your certificate and the details of your Fortanix account using the Imperva API.

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.

• Remove certificate: Remove the certificate from Imperva.

• 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.

View certificate status


After you upload your certificate to Imperva, you can see the status in the Cloud Security Console on the
SSL Certificates page. For details, see Manage SSL Certificates.

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.

For details, see SSL Certificates API Definition.

See also:

• API Key Management

• Authentication

Cloud Application and Network Security 29


Cloud Application and Network Security

Last updated: 2024-04-21

Revalidate Your Imperva Certificate


This topic describes how to complete the certificate revalidation process, which includes revalidating ownership of
your domains.

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.

Validate ownership of your websites


When a certificate's deadline arrives, any domains on its list that have not been revalidated will be removed from the
new certificate and they will lose SSL coverage.

To view all your websites that require ownership revalidation:

1. On the SSL Certificates page, Certificates section, a domain that is set to expire has SAN status: Pending user
action.

Cloud Application and Network Security 30


Cloud Application and Network Security

2. Validate the domain by updating the DNS records or by email.

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.

Last updated: 2024-04-21

Adding Emails for Ownership Validation


You can use email validation to validate your sites that have an Imperva-generated certificate. The Certificate
Authority validates site ownership when you add the site and when you revalidate the Imperva-generated certificate,
by sending a validation link to one of the email addresses listed on the site's DNS records, specifically, in the
subdomain
"_validation-contactemail"
.

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.

Add an email address to the DNS record


Each email address needs to be a separate DNS TXT entry. Repeat these steps for each email address you want to add
for site ownership validation.

1. Access your site's DNS record.

2. Create a TXT record on the subdomain


"_validation-contactemail"
. If the subdomain doesn't exist, create it.
The entire value of this TXT record must be a valid email address, without any additional padding or structure.

Cloud Application and Network Security 31


Cloud Application and Network Security

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.

_validation-contactemail.altostrat.com 400 IN TXT [email protected]

For more details, see:

• Onboarding a Site – Web Protection and CDN

• Revalidate Your Imperva Certificate

Last updated: 2024-04-21

Customize Website TLS Configuration


Customize the TLS versions and cipher suites used by Imperva for connectivity between your website visitors and the
Imperva service.

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.

View or modify the TLS configuration


The Imperva API enables you to view or modify your website's current TLS configuration.

For full details on the Website TLS Configuration API, see Website Management API Definition.

You can configure the following for a website:

• supported TLS versions

• supported cipher suites per TLS version

• HSTS configuration

Cloud Application and Network Security 32


Cloud Application and Network Security

Use the https://api.imperva.com/sites-mgmt/v3/sites/{siteId}/settings/TLSConfiguration endpoint to set the


TLS configuration.

You can choose one of the configuration profiles:

• 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"
]
}
]
}

Supported cipher suites per profile


For the full list of supported ciphers for each predefined configuration profile, see Supported Cipher Suites.

Last updated: 2024-06-03

Supported Cipher Suites


The following cipher suites are supported by default by Imperva for secure communication over HTTPS.

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.

Cloud Application and Network Security 33


Cloud Application and Network Security

ECC/RSA certificate cipher suite support


The TLS 1.3 ciphers listed below are supported by both RSA and ECC certificates.

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.

Supported ciphers between visitors and Imperva


TLS 1.3

Supported by these Imperva


Standard Name (RFC) OpenSSL Name
predefined profiles

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

Supported by these Imperva


Standard Name (RFC) OpenSSL Name
predefined profiles

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

Cloud Application and Network Security 34


Cloud Application and Network Security

Supported by these Imperva


Standard Name (RFC) OpenSSL Name
predefined profiles

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

Cloud Application and Network Security 35


Cloud Application and Network Security

TLS 1.1 and 1.0

Supported by these Imperva


Standard Name (RFC) OpenSSL Name
predefined profiles
TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA None
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA None
TLS_ECDHE_RSA_WITH_AES_128_CB
ECDHE-RSA-AES128-SHA None
C_SHA
TLS_ECDHE_RSA_WITH_AES_256_CB
ECDHE-RSA-AES256-SHA None
C_SHA

Supported ciphers between Imperva and the origin server


Imperva proxies connect to the origin server declaring support for TLS 1.3.

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

Standard Name (RFC) OpenSSL Name


TLS_AES_128_GCM_SHA256 TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256 TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384 TLS_AES_256_GCM_SHA384

TLS 1.2

Standard Name (RFC) OpenSSL Name


TLS_ECDHE_RSA_WITH_AES_256_GC
ECDHE-RSA-AES256-GCM-SHA384
M_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_
ECDHE-ECDSA-AES256-GCM-SHA384
GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GC
ECDHE-RSA-AES128-GCM-SHA256
M_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_
ECDHE-ECDSA-AES128-GCM-SHA256
GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CB
ECDHE-RSA-AES256-SHA384
C_SHA384

Cloud Application and Network Security 36


Cloud Application and Network Security

Standard Name (RFC) OpenSSL Name


TLS_ECDHE_ECDSA_WITH_AES_256_
ECDHE-ECDSA-AES256-SHA384
CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CB
ECDHE-RSA-AES256-SHA
C_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_
ECDHE-ECDSA-AES256-SHA
CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CB
ECDHE-RSA-AES128-SHA256
C_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_
ECDHE-ECDSA-AES128-SHA256
CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CB
ECDHE-RSA-AES128-SHA
C_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_
ECDHE-ECDSA-AES128-SHA
CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_
ECDHE-RSA-DES-CBC3-SHA
CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_ED
ECDHE-ECDSA-DES-CBC3-SHA
E_CBC_SHA
TLS_ECDHE_RSA_WITH_CHACHA20_
ECDHE-RSA-CHACHA20-POLY1305
POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA2
ECDHE-ECDSA-CHACHA20-POLY1305
0_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_
DHE-RSA-AES128-SHA
SHA
TLS_DHE_DSS_WITH_AES_128_CBC_
DHE-DSS-AES128-SHA
SHA
TLS_DHE_RSA_WITH_AES_256_CBC_
DHE-RSA-AES256-SHA
SHA
TLS_RSA_WITH_AES_256_GCM_SHA
AES256-GCM-SHA384
384
TLS_RSA_WITH_AES_128_GCM_SHA
AES128-GCM-SHA256
256
TLS_RSA_WITH_AES_256_CBC_SHA2
AES256-SHA256
56
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
TLS_RSA_WITH_AES_128_CBC_SHA2
AES128-SHA256
56

Cloud Application and Network Security 37


Cloud Application and Network Security

Standard Name (RFC) OpenSSL Name


TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SH
DES-CBC3-SHA
A

See also:

• Web Protection - SSL/TLS

Last updated: 2024-04-21

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.

A CA can issue certificates for domains with one of the following:

• 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.

What do I need to do?


If your domain is using CAA, make sure you have the CAA
Before onboarding an SSL site:
records required by Imperva.

Before configuring SSL for an existing site: 1. If your domain is using CAA, make sure you have
the CAA records required by Imperva.

Cloud Application and Network Security 38


Cloud Application and Network Security

2. In the Imperva Cloud Security Console, navigate to


Websites > Website Settings > General.
3. In the SSL Support section, under Actions, click
Test CAA records to verify your configuration.

To ensure a smooth renewal process at the end of a


certificate's validity period, add the required CAA records
For an existing SSL site: to your DNS. If your domain is non-compliant, Imperva
may disable SSL support. Email notifications are sent to
you prior to any action taken by Imperva.

Configure CAA records


Prerequisite: Your domain's DNS software or provider must support CAA.

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"

Last updated: 2024-04-21

Client Certificate 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.

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.

Cloud Application and Network Security 39


Cloud Application and Network Security

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.

Last updated: 2024-05-20

Client-to-Imperva Client Certificate mTLS Support


To support client certificates, upload your client CA certificate to Imperva and configure your websites to use it.

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.

For example, Imperva client certificate support enables you to:

• Apply a second factor of authentication


• Validate device authenticity and avoid forgery
• Validate the authenticity of the mobile app used to access your website

Configuring client certificate support for a website includes the following steps:

1. Upload a CA certificate to your account.


2. Assign the certificate to websites in your account.

3. Configure optional client certificate support settings for your websites.

Note:

• When enabling Client to Imperva mTLS, it can take up to 10 minutes for changes to take effect.

Cloud Application and Network Security 40


Cloud Application and Network Security

• 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:

• Manage client CA certificates for account


• Manage client CA certificates for site
• View client CA certificates

The Client to Imperva (mTLS) Certificates pages are displayed only to users with the appropriate permissions.

Open the Client to Imperva (mTLS) Certificates configuration pages


The Client to Imperva (mTLS) Certificates pages enable you to manage the certificates for your account and websites.

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.

1. On the top menu bar, click Application.


2. On the sidebar, click SSL/TLS > Client to Imperva (mTLS).

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.

2. Under SSL/TLS, click Client to Imperva (mTLS).

Upload a CA certificate to your account


Upload the CA certificate that is used to sign all client certificates. Then assign it to websites in your account.

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.

Cloud Application and Network Security 41


Cloud Application and Network Security

Option Description
Uploaded file The file name of the uploaded certificate file.
Name Give a descriptive name to the certificate.

Assign this certificate to the selected websites.


Assign to websites
The drop-down includes all websites in the account that
are configured for SSL and using a custom certificate.

Assign a certificate to a website after upload


To assign a certificate to websites after the upload process, or change the assigned websites, do one of the following:

• 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.

Configure client certificate support settings


Configure client certificate support settings for a website on the website-level Client to Imperva (mTLS) Certificates
page, under Configuration Settings.

Note: These settings apply to all certificates assigned to the website.

Option Description

When enabled, the end-user is required to present the


certificate during the initial TLS handshake in order to
Require client certificate access the site.

By default, the client certificate is not required.

If client authentication is also required, the


authentication information can be sent to your origin
Send client certificate details to origin server
server. The information is sent in a header added by
Imperva to the client request before it is sent on to the
origin server.

Cloud Application and Network Security 42


Cloud Application and Network Security

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.

Header name: The name of the header to send header


content in. By default, the header name is
clientCertificateInfo.

Header value: The content to send in the header


specified in the Header name field. Options include:

• Full client certificate: The full CA certificate in


Base64 (ASCII).
• Fingerprint: The CA certificate's fingerprint in
SHA1.
• Common name: The CA certificate's common
name (CN).
• Serial number: The CA certificate's serial number.

Note: For more details, see Send client certificate details


to origin server below.

Enable and/or disable client certificate support on


specific hosts and ports.

Enter the specific hosts or ports on which to enable or


disable the feature.
Restrict client certificate support
For multiple hosts or ports, enter a comma-separated
list.

If left blank, client certificates are supported for all hosts/


ports.

To limit access, you can provide the SHA fingerprint of


specific client certificates.
Restrict client certificate fingerprints
If left blank, all fingerprints are accepted.

For multiple fingerprints, enter a comma-separated list.

Cloud Application and Network Security 43


Cloud Application and Network Security

View certificate details


You can view details for client CA certificates on the Client to Imperva (mTLS) Certificates page in your account or
website.

• 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

(Optional) The user-provided name for the certificate.


Name
If a name is not provided, the file name of the uploaded
certificate is used by default.

Serial Number The certificate's serial number.


The name of the Certificate Authority (CA) that issued the
Issuer
certificate.
Valid From The first day of the certificate's validity period.
Valid To The last day of the certificate's validity period.

The date the certificate was uploaded to the account.


Creation Date
Available from: Account-level page only.

Enables you to rename the certificate, or change the


websites to which the certificate is assigned.
Edit (under More)
Available from: Account-level page only.

Account-level page: Deletes the certificate from your


account.

Note: You cannot delete a certificate from the account


Delete (under More)
when it is assigned to websites.

Website-level page: Removes the certificate from the


specific website.

Cloud Application and Network Security 44


Cloud Application and Network Security

Send client certificate details to origin server


In this section:

• Send client certificate details to origin server


• Sending additional client parameters to the origin server
• Convert header details into a certificate object

Send client certificate details to origin server

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.

Sending additional client parameters to the origin server

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.

Convert header details into a certificate object

After you receive the client certificate information, you can convert it into a certificate object.

Here is an example using ASP.NET code:

byte[] clientCertBytes = Convert.FromBase64String(certHeader);


certificate = new X509Certificate2(clientCertBytes);

Here is an example using Java code:

byte[] clientCertificateBytes = Base64.getDecoder().decode(certHeader);


certificate = CertificateFactory.getInstance("X.509").generateCertificates(new ByteArrayInputS

Client certificate validation using a CRL


Once 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. For details, see Upload a CRL.

Certificate Manager API


You can also upload and manage client certificates and CRLs via the API. For details, see Certificate Manager API.

Last updated: 2024-06-03

Cloud Application and Network Security 45


Cloud Application and Network Security

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.

Upload a CRL file


For instructions on uploading a CRL file, see the Certificate Manager API.

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.

Last updated: 2024-04-21

Certificate Manager API


Upload and manage CA certificates and CRL files for your account to use for client certificate support.

Client certificate APIs


If your site needs to support client certificates, you can use the API to upload your CA certificate to your Imperva
account, and then configure your websites to use it.

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.

Certificate Manager API Definition


For instructions on using the Certificate Manager API, see Certificate Manager API Definition.

These APIs enable you to manage the Client to Imperva (mTLS) feature, which supports mutual authentication
between your end users and Imperva.

Cloud Application and Network Security 46


Cloud Application and Network Security

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:

• Client-to-Imperva Client Certificate mTLS Support


• Upload a CRL

Last updated: 2024-06-03

Certificate Manager API Definition


Certificate Manager API
Configure client certificate support for your websites or web applications.

Manage and upload a Certificate Revocation List (CRL) file to verify whether certificates are valid and trustworthy.

For full feature documentation, see Client Certificate Support.


More information: https://helloreverb.com
Contact Info: [email protected]
Version: 1.0
BasePath:/certificate-manager
Imperva License Agreement
https://www.imperva.com/legal/license-agreement/

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}

Cloud Application and Network Security 47


Cloud Application and Network Security

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

Cloud Application and Network Security 48


Cloud Application and Network Security

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

Cloud Application and Network Security 49


Cloud Application and Network Security

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

Cloud Application and Network Security 50


Cloud Application and Network Security

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

failed to send CRL


Up
delete /sites/{siteId}/CRL/{crlId}
Remove CRL from site (removeCRL)

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

Cloud Application and Network Security 51


Cloud Application and Network Security

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"
}

Cloud Application and Network Security 52


Cloud Application and Network Security

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

failed to add ca certificate


Up
post /v2/sites/{siteId}/client-certificates/{certId}
Assign client CA certificate of the account to site (assignSiteToCertificate)

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

Cloud Application and Network Security 53


Cloud Application and Network Security

401

unauthorized site

406

bad request

500

failed to assign ca certificate to site


Up
delete /v2/sites/{siteId}/client-certificates/{certId}
Remove client CA certificate from site (deassignCertFromSite)

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

failed to remove ca certificate from site


Up
delete /v2/accounts/{accountId}/client-certificates/{certId}
Delete client CA certificate from account (deleteClientCaCert)

Cloud Application and Network Security 54


Cloud Application and Network Security

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

Could not delete certificate


Up
put /v2/sites/{siteId}/configuration/client-certificates
Overwrite the client CA certificate configuration (full update) (fullUpdateSiteConfiguration)

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

Cloud Application and Network Security 55


Cloud Application and Network Security

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

Cloud Application and Network Security 56


Cloud Application and Network Security

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

Cloud Application and Network Security 57


Cloud Application and Network Security

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]

Cloud Application and Network Security 58


Cloud Application and Network Security

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)

Cloud Application and Network Security 59


Cloud Application and Network Security

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)

Cloud Application and Network Security 60


Cloud Application and Network Security

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

Cloud Application and Network Security 61


Cloud Application and Network Security

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

Cloud Application and Network Security 62


Cloud Application and Network Security

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)

Cloud Application and Network Security 63


Cloud Application and Network Security

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)

Cloud Application and Network Security 64


Cloud Application and Network Security

String CRL name

Last updated: 2024-04-21

Imperva-to-Origin Client Certificate mTLS Support


Upload your client certificate to Imperva to enable mutual authentication between Imperva and your origin servers.

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.

• View Imperva to Origin mTLS certificates

• Manage Imperva to Origin mTLS certificates for account

Cloud Application and Network Security 65


Cloud Application and Network Security

Process overview

Follow these steps to configure mTLS for Imperva-to-origin communication:

1. Prepare the client certificate, according to the guidelines below.

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.

Open the Imperva to Origin certificates page


To upload and manage certificates:

1. Log in to your account in the Imperva Cloud Security Console.


2. On the top menu bar, click Application.
3. On the sidebar, click SSL/TLS > Imperva to Origin (mTLS).

Prepare the client certificate


The client certificate must conform to the following guidelines:

• Both RSA and ECC certificates are supported.

• 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

Upload the client certificate


To configure client certificate support, you upload your client certificate to your Imperva account, and then configure
your websites to use it.

To upload a certificate, open the Imperva to Origin (mTLS) Certificates page and click Add.

Follow the onscreen instructions to:

1. Upload your client certificate

2. Upload the RSA private key

3. Assign to websites (optional - you can do this at a later time). For details, see Assign the certificate to websites
below.

Cloud Application and Network Security 66


Cloud Application and Network Security

Assign the certificate to websites


Once you have uploaded a certificate to Imperva, you can assign it to websites in your account.

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:

Indicates if there is already a certificate assigned to a


website. If you select websites that already have a
Applied certificate
certificate assigned to them, the existing certificate is
replaced by the new one you assign.

The name of the account or subaccount where the


Parent account
website is defined.

3. Select the websites you want to assign this certificate to and click Apply.

Configure your origin server


To support mutual authentication between Imperva and your origin server, you must configure your origin server. The
server needs to require clients to authenticate using mTLS certificates issued by your CA.

Configuration varies between different web servers. Consult the server's documentation for specific instructions.

Here is an example of mutual TLS configuration on an NGNIX server:

Configuration file: /etc/nginx/nginx.conf

# 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

View and manage certificates


View and manage the certificates uploaded to your account.

Cloud Application and Network Security 67


Cloud Application and Network Security

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.

Details of the Certificate Authority that issued the


certificate, including:

EMAILADDRESS

CN: Common Name

OU: Organizational Unit


Issuer
O: Organization

L: Locality

ST: State or Province Name

C: Country Name

The certification path, from the uploaded certificate back


Chain to the root certificate, where each certificate has been
signed by the next one in the chain.

Valid from The date the certificate was issued.

Expiration date The date the certificate expires.

The number of websites in the account to which the


certificate is applied.
Applied websites
Click to number to view the website details.

Click the ellipsis on a certificate row to access these


additional options:

• Edit. Enables you to replace the certificate.

• Delete. Deletes the certificate from your account.

Cloud Application and Network Security 68


Cloud Application and Network Security

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.

• Assign to websites. Assign the certificates to


websites in your account. For more details, see
Assign the certificate to websites.

Audit trail
The following events are logged in the audit trail for your account:

• mTLS Imperva to origin certificate added

• mTLS Imperva to origin certificate updated

• mTLS Imperva to origin certificate deleted

• mTLS Imperva to origin certificate assigned to website

• mTLS Imperva to origin certificate removed from website

For more details, see Audit Trail.

Last updated: 2024-05-20

SSL Certificates API Definition


SSL Certificate Management
View and manage certificates for all websites in your account.
More information: https://helloreverb.com
Contact Info: [email protected]
Version: 1.0.0
BasePath:/certificates-ui
The terms in the absence of an applicable signed agreement between you and Imperva
https://www.imperva.com/legal/license-agreement/

Access
1. APIKey KeyParamName:x-API-Id KeyInQuery:false KeyInHeader:true

Cloud Application and Network Security 69


Cloud Application and Network Security

2. APIKey KeyParamName:x-API-Key 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.

Cloud Application and Network Security 70


Cloud Application and Network Security

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

Successful operation HsmLatencyDetailsResponse

400

Bad Request APIErrors

500

Internal Error APIErrors

Cloud Application and Network Security 71


Cloud Application and Network Security

504

Gateway Timeout Request APIErrors

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"
}, {

Cloud Application and Network Security 72


Cloud Application and Network Security

"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

Successful operation ChangeValidationMethodExternalResponse

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
get /v3/certificates
Get certificate details (getCertificates1)
Get details for certificates in your account.

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

Cloud Application and Network Security 73


Cloud Application and Network Security

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,

Cloud Application and Network Security 74


Cloud Application and Network Security

"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

Successful operation Certificate

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
get /v3/instructions
Get domain validation instructions (sanInstructionsForAccount)
Get validation instructions for all pending SANs in the account

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",

Cloud Application and Network Security 75


Cloud Application and Network Security

"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

Successful operation SanInstructionsDto

401

Unauthorized APIErrors

500

Internal Server Error APIErrors

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

Cloud Application and Network Security 76


Cloud Application and Network Security

{
"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"

Cloud Application and Network Security 77


Cloud Application and Network Security

}, {
"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

Successful operation AccountSSLSettingsResponseDto

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
delete /v3/account/ssl-settings
Reset SSL settings to default (deleteSSLValidationDelegationSettings)
Resets SSL settings for your account to the default values.

Return type
AccountSSLSettingsResponseDto

Example data
Content-Type: application/json

Cloud Application and Network Security 78


Cloud Application and Network Security

{
"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"

Cloud Application and Network Security 79


Cloud Application and Network Security

}, {
"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

Successful operation AccountSSLSettingsResponseDto

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
get /v3/account/ssl-settings
Get account SSL settings (getSSLValidationDelegationSettings)
Get SSL settings for your account.

Return type
AccountSSLSettingsResponseDto

Example data
Content-Type: application/json

Cloud Application and Network Security 80


Cloud Application and Network Security

{
"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"

Cloud Application and Network Security 81


Cloud Application and Network Security

}, {
"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

Successful operation AccountSSLSettingsResponseDto

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
patch /v3/account/ssl-settings
Modify SSL settings (partial update) (patchSSLValidationDelegationSettings)
Updates the SSL settings that you send in the request. Other settings remain as is.

Consumes
This API call consumes the following media types via the Content-Type request header:

• application/json

Cloud Application and Network Security 82


Cloud Application and Network Security

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,

Cloud Application and Network Security 83


Cloud Application and Network Security

"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

Successful operation AccountSSLSettingsResponseDto

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
delete /v3/account/ssl-settings/delegation/domain/{domainId}

Cloud Application and Network Security 84


Cloud Application and Network Security

Remove domain from the SSL validation delegation settings (removedDomainToSSLValidationDelegationSettings)


Remove domain from the SSL validation delegation settings of your account. Certificate renewal may require you to
revalidate domain ownership.

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,

Cloud Application and Network Security 85


Cloud Application and Network Security

"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

Successful operation AccountSSLSettingsResponseDto

400

Bad Request APIErrors

Cloud Application and Network Security 86


Cloud Application and Network Security

500

Internal Error APIErrors


Up
post /v3/account/ssl-settings
Overwrite SSL settings (full update) (updateSSLValidationDelegationSettings)
Update SSL settings for your account.

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",

Cloud Application and Network Security 87


Cloud Application and Network Security

"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

Cloud Application and Network Security 88


Cloud Application and Network Security

Responses

200

Successful operation AccountSSLSettingsResponseDto

400

Bad Request APIErrors

500

Internal Error APIErrors


Up
post /v3/account/ssl-settings/delegation/domain/{domainId}/status
Check the configuration status of a domain that appears in the domain delegation list
(verifyDomainToSSLValidationDelegationSettings)
Check if the CNAME record has been added to the domain's DNS zone.

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,

Cloud Application and Network Security 89


Cloud Application and Network Security

"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

Successful operation AllowDelegationDomainWithInheritanceResponseDto

400

Bad Request APIErrors

500

Internal Error APIErrors

Models
Methods

Table of Contents

1.
APIError
2.
APIErrors
3.
AccountDtoSSLDelegationSettingsDto
4.
AccountSSLSettingsResponseDto
5.
AccountSettingsDto
6.
AllowDelegationDomainWithInheritanceResponseDto
7.
AllowDomainDelegationWithInheritance
8.
Certificate
9.

Cloud Application and Network Security 90


Cloud Application and Network Security

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)

Cloud Application and Network Security 91


Cloud Application and Network Security

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

Cloud Application and Network Security 92


Cloud Application and Network Security

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)

Cloud Application and Network Security 93


Cloud Application and Network Security

array[CertificateSanDetails] List of Subject Alternative Names found on the certificate


extSiteId (optional)
Long The Imperva ID of the onboarded website covered by the certificate format: int64
example: 856963
siteName (optional)
String The name of the onboarded website covered by the certificate
example: Site Name
authType (optional)
String The authentication type of the certificate
Enum:
RSA
ECC
example: RSA
level (optional)
String The level of the certificate (SITE or ACCOUNT)
Enum:
SITE
ACCOUNT
example: SITE
customCertificateDetails (optional)
CustomCertificateDetails

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)

Cloud Application and Network Security 94


Cloud Application and Network Security

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.

Cloud Application and Network Security 95


Cloud Application and Network Security

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

Cloud Application and Network Security 96


Cloud Application and Network Security

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

Cloud Application and Network Security 97


Cloud Application and Network Security

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

Last updated: 2024-04-21

Cloud Application and Network Security 98

You might also like