End of 4- to 6-year Multi-year Plans for public TLS/SSL and VMC certificates

On October 31, 2023, DigiCert will no longer sell 4- to 6-year Multi-year Plans for TLS and VMC certificates. We will continue to offer 1, 2, and 3-year Multi-year Plans.

Starting October 31, 2023, API requests to create an order for public TLS or VMC certificates with a validity exceeding 3 years will return an HTTP response status code of 400 Bad Request with the following error:

{
  "errors": [
    {
      "code": "invalid_value:<validity_duration_unit>",
      "message": "<validity_duration_unit> contains an invalid value."
    }
  ]
}

In the error you receive, <validity_duration_unit> will reflect the validity duration unit used in the order request:

validity_years
validity_days
custom_expiration_date

What do I need to do?

If you use the CertCentral Services API to create orders for TLS or VMC certificates, complete the following before October 31, 2023 to avoid service disruptions:

In your client integration code, check for POST requests to create an order. Affected endpoints include:
- Any POST request to create an order for public DV, OV, or EV TLS certificates. See Orders.
- Any POST request to create an order for a Verified Mark Certificate (VMC).
In the requests you find, check the value your integration provides for the order validity parameter in the request payload.
Does your integration submit requests to create orders that are valid for more than 3 years?
- Yes, it does.
  Update your integration. Make sure your requests use order validity values within the range of values allowed after October 31, 2023.
- No, it doesn't.
  No action required.

Order validity parameters and allowed values

The CertCentral Services API supports two options for defining order validity in requests to create an order:

Use the order_validity object in the root of the request body. Then, in the order_validity object, provide a value for a validity duration unit: years, days, or custom_expiration_date.
Example 1. order_validity.years
```
{
  ...
  "order_validity: {
    "years": 1
  },
  ...
}
```
Example 2. order_validity.days
```
{
  ...
  "order_validity: {
    "days": 365
  },
  ...
}
```
Example 3. order_validity.custom_expiration_date
```
{
  ...
  "order_validity: {
    "custom_expiration_date": "09 JUN 2025"
  },
  ...
}
```
Use one of the following parameters in the root of the request body: validity_years, validity_days, or custom_expiration_date.
Example 4. validity_years
```
{
  ...
  "validity_years": 1,
  ...
}
```
Example 5. validity_days
```
{
  ...
  "validity_days": 365,
  ...
}
```
Example 6. custom_expiration_date
```
{
  ...
  "custom_expiration_date": "2025-06-09",
  ...
}
```

Regardless of whether you use the order_validity object or provide a validity duration unit in the root of your request body, the range of allowed values is the same.

Table 1. Allowed order validity values

Request parameter	Current maximum	Maximum after October 31, 2023
`validity_years` `order_validity.years`	6	3
`validity_days` `order_validity.days`	2190	1095
`custom_expiration_date` `order_validity.custom_expiration_date`	Within 6 years of date submitted	Within 3 years of date submitted

In this section:

End of 4- to 6-year Multi-year Plans for public TLS/SSL and VMC certificates

What do I need to do?

Order validity parameters and allowed values

Search results