Veeam Internal CA Certificate Requirements: Fixing the Basic Constraints Error 

A PKI team finishes configuring Veeam Backup & Replication to use a certificate issued by its internal Certificate Authority (CA), but Veeam rejects it. The certificate has the right FQDN, the right key size, and a valid chain to a trusted root. However, it fails an unusual requirement in Veeam’s documentation: the certificate’s Basic Constraints extension must have Subject Type set to CA and Path Length Constraint set to 0, which prevents it from issuing subordinate CA certificates. 

Veeam Backup & Replication is a backup and replication platform for virtualized, physical, and cloud workloads, built around three logical components: the backup server, one or more backup proxies, and a backup repository. Many organizations secure communication between these components with a certificate from their own internal CA rather than a public one, and that choice is what triggers Veeam’s Basic Constraints requirement. 

This blog explains what that requirement actually means, why it looks more restrictive than it is, and how to scope the fix to a single certificate template in Microsoft AD CS rather than to the CA itself.

Key Takeaways 

• Veeam requires a certificate (Basic Constraints: Subject Type = CA, Path Length = 0) for any TLS certificate signed by an internal CA, as documented in the current VBR 13 User Guide. 
• Path Length = 0 is a property of that one certificate, not a policy on the issuing CA. Don’t lock down the whole CA to satisfy it. 
• The fix belongs in a dedicated certificate template’s Basic Constraints checkbox, scoped to that template alone. 
• “Offline CRL Signing” and “CRL Signing” are the same key usage bit (0x2) in Microsoft’s X509KeyUsageFlags enumeration: one checkbox covers both. 
• Duplicating a built-in template produces a version 3 or 4 template that native AD CS web enrollment can’t issue; use the MMC snap-in, certreq, or certificate lifecycle management tool. 

Why Organizations Use an Internal CA for Veeam’s Certificate 

Once Veeam is in place, securing communication between its components comes down to choosing where the TLS certificate comes from. Issuing it from an internal CA instead of a public one gives an organization three things: mutual authentication between Veeam’s components, encrypted traffic between them, and centralized control over issuance, renewal, and revocation, all without depending on an external certificate authority. 

For this to work, the systems validating Veeam’s certificate must be able to build a valid certificate chain back to a trusted Root CA. In domain-joined Windows environments where the Root CA certificate is already distributed through Group Policy, the necessary trust may already be established, provided intermediate certificates and revocation information are accessible. Once an organization decides to issue the certificate through its internal CA, Veeam specifies additional certificate requirements, including one that may seem unusual at first glance. 

An important distinction is that while Veeam can back up Windows servers hosting Domain Controllers and Certificate Authorities, these backups alone do not constitute a complete PKI disaster recovery (DR) strategy. A comprehensive PKI recovery plan must also account for AD CS database and configuration backups, CA private key protection and recovery, HSM-specific recovery procedures where applicable, and tested restoration processes. Offline Root CAs may also require a separate backup and recovery approach. This blog focuses specifically on Veeam’s certificate requirements rather than the backup and recovery of the underlying PKI infrastructure. 

Veeam’s Basic Constraints Certificate Requirement 

Veeam publishes a fixed set of certificate requirements for any TLS certificate signed by an internal CA, and the list stays consistent across the VBR, Hyper-V, vSphere, and Agent guides. The table below reflects the requirements published in the VBR 13 User Guide: 

Field	Requirement
Subject	Fully qualified domain name (FQDN) of the Veeam Backup & Replication server
Subject Alternative Name	Both the FQDN and the NetBIOS name
Key size	Minimum 2048 bits
Key usage	Digital Signature Certificate Signing Off-line CRL Signing CRL Signing (06)
Basic Constraints	The Path Length Constraint parameter must be set to 0. The Subject Type parameter must be set to CA.
Key type	Exchange
Not supported	Certificates issued by a public CA, Elliptic Curve Signature (ECC) certificates, Cryptography API: Next Generation (CNG) certificates

The Basic Constraints requirement is where the confusion often begins. A certificate configured with Subject Type = CA and Path Length = 0 is technically a CA certificate, but it cannot have any subordinate CA certificates beneath it in a valid certification path. This can easily be misinterpreted as a requirement to restrict the Issuing CA itself, preventing it from issuing further subordinate CA certificates. Such an interpretation creates a conflict in environments where the same Issuing CA must continue supporting subordinate CA hierarchies. The key distinction is that this requirement applies to the certificate being configured for Veeam, not to the Issuing CA’s own certificate or its broader issuance capabilities.

Is Offline CRL Signing a Separate Key Usage Setting? 

Veeam’s key usage requirement lists Certificate Signing, Offline CRL Signing, and CRL Signing as separate items. A certificate template’s Key Usage tab has a box for CRL Signing, but nothing labeled “Offline,” which looks like a missing setting. It is not. Microsoft’s X509KeyUsageFlags enumeration (certenroll.h) defines both XCN_CERT_OFFLINE_CRL_SIGN_KEY_USAGE and XCN_CERT_CRL_SIGN_KEY_USAGE at the same value, 0x2. They are two names for the identical cRLSign bit in the X.509 Key Usage extension. Checking CRL Signing in the template already satisfies the documented requirement for Offline CRL Signing; there is no second box to find. 

How to Scope the Fix to a Single Certificate Template

Once Veeam’s certificate requirements are understood, the next step is determining where those requirements should be applied. The Basic Constraints requirement applies specifically to the certificate issued for Veeam, not to the Issuing CA’s own certificate or its overall ability to issue subordinate CA certificates. 

Before making any configuration changes, verify the following: 

• Check the Issuing CA certificate: Open certsrv.msc on the Issuing CA server and navigate to Properties → General → View Certificate → Details → Basic Constraints to verify whether the active CA certificate has a path length restriction. 
• Check the CA-wide path length policy: Run certutil -getreg Policy\CAPathLength to determine whether a path length restriction is configured at the CA policy level. 
• Review the CA renewal configuration: Open C:\Windows\CAPolicy.inf on the Issuing CA server and check for the [BasicConstraintsExtension] section. Any configured path length settings should be reviewed for their potential effect on future CA certificate renewals. However, the absence of this section does not establish the constraints of the currently issued CA certificate. 

The recommended approach is to configure a dedicated certificate template for Veeam rather than modifying the Issuing CA’s certificate or applying a CA-wide restriction. 

Duplicate the built-in Subordinate Certification Authority template and navigate to Extensions → Basic Constraints. Enable Do not allow subject to issue certificates to other CAs, which configures a path length constraint of 0. Also enable Make this extension critical, as specified in Veeam’s documentation. 

After configuring the remaining certificate requirements, publish the dedicated template on the Issuing CA and use it to issue the Veeam certificate. 

This approach limits the configuration change to certificates issued through the dedicated Veeam template, without modifying the Issuing CA’s existing certificate or other certificate templates. However, any path length restrictions already imposed by the CA hierarchy or CA-wide policy will continue to apply. 

What Happens If You Change the CA’s Policy Instead of the Template 

The narrower fix above is deliberate. The alternative, setting the CA’s policy-module default, Policy\CAPathLength, to 0 or 1, produces a certificate with the same Basic Constraints value, but changes the CA’s behavior for every certificate it issues from that point on, through every template, until someone reverts the value and restarts the CA service. 

If the same Issuing CA also supports subordinate CAs that need to issue further intermediate CA certificates, applying a path length restriction at the CA-wide policy level can affect certificates issued under that configuration. These certificates may still be issued successfully but contain a path length constraint that prevents the intended CA hierarchy from functioning correctly. 

Under RFC 5280, Section 6.1.4, certification path validation enforces path length constraints. If a certificate chain exceeds the permitted number of subordinate CA levels, a conforming Relying Party will reject the chain. As a result, an incorrectly applied restriction may not cause an immediate issuance failure but can lead to certificate validation failures later, when additional intermediate CAs are introduced. This makes the issue particularly difficult to detect during initial certificate issuance and reinforces the importance of applying the restriction only where required.

Mechanism	Scope	Reversible without disruption	Production risk
Template’s Basic Constraints checkbox	One template only	Yes. No CA restart; affects only certificates issued after the change.	Low
CA-wide registry default (Policy\CAPathLength)	Every certificate from that CA, until reverted	No. Requires stopping and restarting the CA service.	Medium to high
CAPolicy.inf on the CA’s own certificate	The CA itself and everything chained to it	No. Requires re-keying or renewing the CA certificate and redistributing it.	High

For a single certificate requirement like Veeam’s, the template checkbox does the job with the smallest blast radius. Reach for the registry default or a CA re-key only when something specifically requires a CA-wide or CA-identity-level change, not as a shortcut for one certificate. 

How to Configure a Veeam-Compliant Certificate Template in AD CS 

With the scope decided, building the template is straightforward. This assumes the two checks above came back clean, and that the requirements table matches the installed Veeam version. 

1. Duplicate the built-in Subordinate Certification Authority template rather than building one from scratch. It’s the closest match to a certificate that has to be CA-shaped. 
2. Set the compatibility levels on the CA and the certificate recipient to match the actual OS of your Veeam server and your CA. 
3. On the Extensions tab, configure Basic Constraints: check “Do not allow subject to issue certificates to other CAs” (this writes CA = true with Path Length = 0) and mark the extension critical. 
4. Confirm Key Usage includes Digital Signature, Certificate Signing, and CRL Signing. CRL Signing and Offline CRL Signing are the same bit, so there’s no second box. 
5. Leave Subject, SAN, key size, and key type to the request itself. These are not template settings; whoever submits the CSR specifies the FQDN and NetBIOS SAN, a key size of at least 2048 bits, and key type Exchange. 
6. Name the template clearly and restrict who can enroll against it. A CA-shaped template is sensitive regardless of its path length restriction. 
7. Decide whether the certificate needs AD publishing. Veeam retrieves and consumes its own certificate directly, so this is usually unnecessary; confirm this against your own AD CS design. 
8. Request the certificate through the Certificates MMC snap-in, certreq, or a certificate lifecycle management tool. Duplicating a built-in template on a current Windows Server CA typically produces version 3 or 4 template, and native AD CS web enrollment pages can’t offer version 3 templates for request. 
9. Validate the issued certificate against every requirement in the table above, and confirm the CRL is reachable from the Veeam server before deploying it. 

Once the certificate has been issued and validated, the final consideration is ensuring that these application-specific requirements remain isolated from the broader CA configuration. 

Our Recommendation 

Most of the confusion around this requirement comes from interpreting Subject Type = CA as an instruction to modify the Certificate Authority itself, rather than as a property of the certificate being issued. The appropriate approach is to use a dedicated certificate template for Veeam, restrict enrollment permissions to authorized administrators or service identities, and avoid changing CA-wide policies to meet an application-specific requirement. 

This is a pattern we see repeatedly in PKI engagements. Under deployment pressure, teams may choose a broader configuration change, such as modifying a CA-wide registry setting or updating CAPolicy.inf, without fully considering its impact on the existing CA hierarchy. While the resulting certificate may meet Veeam’s requirements, an improperly scoped change can introduce restrictions that affect other applications or subordinate CAs. These issues may only become apparent later, when certificate chain validation fails, making the original configuration change difficult to identify as the cause. 

Using a dedicated certificate template helps prevent such unintended consequences by keeping application-specific requirements separate from broader CA configurations. 

As organizations introduce more applications requiring specialized certificates, including backup platforms, network appliances, and other infrastructure services, managing these templates becomes increasingly important. Maintaining visibility into template configurations, enrollment permissions, certificate purposes, and vendor-specific requirements helps ensure consistency, reduce configuration risks, and support ongoing PKI governance and audit readiness.

Staying Compliant Over Time 

Meeting Veeam’s certificate requirements is not a one-time activity. Regular reviews are essential to maintain compatibility and prevent unintended changes to the PKI environment. 

• Review requirements during upgrades: Verify the certificate requirements against the documentation for the installed Veeam version before major upgrades, as vendor requirements may change between releases. 
• Document the certificate template: Maintain clear records of the template’s name, purpose, configuration, and enrollment permissions to prevent it from being mistaken for a general-purpose CA template. 
• Validate certificate revocation: Ensure the CRL distribution points remain accessible from the Veeam server and that the CRLs use an appropriate signing algorithm, such as RSA with SHA-256, where supported and recommended by the vendor. 
• Avoid unnecessary CA-wide changes: Before modifying CA-wide settings to meet an application-specific requirement, assess the potential impact on existing certificates, subordinate CAs, and dependent applications. 

These practices help maintain certificate compatibility, reduce configuration risks, and ensure that application-specific requirements do not compromise the broader PKI infrastructure. Implementing these practices consistently requires careful certificate template design, policy governance, and PKI expertise, which is where Encryption Consulting can help. 

How Can Encryption Consulting Help 

Configuring certificate templates properly is essential to maintaining a secure and reliable PKI environment. An incorrectly scoped CA-wide configuration change can affect multiple applications and subordinate CAs, potentially leading to certificate validation failures and operational disruptions. 

Encryption Consulting’s PKI Services, including PKI Assessment and PKI Design and Implementation, help organizations establish secure CA hierarchies, define appropriate certificate policies, and implement template configurations that meet application-specific requirements without introducing unnecessary risks to the broader PKI infrastructure. 

For organizations managing multiple certificate templates across their PKI environments, CertSecure Manager helps centralize certificate lifecycle management, improve visibility, and simplify operational oversight. 

Before deploying a certificate in Veeam, organizations can also use Encryption Consulting’s free ASN.1 CSR & Certificate Decoder to inspect certificate extensions, including Basic Constraints and Key Usage, and verify that the issued certificate aligns with the intended configuration. 

By combining secure PKI design, effective certificate management, and proper validation practices, organizations can meet application-specific certificate requirements while maintaining the security, consistency, and reliability of their PKI infrastructure. 

Conclusion 

Veeam’s Basic Constraints requirement applies to the certificate issued for Veeam, not to the Issuing CA’s overall configuration or its ability to issue certificates. Configuring Subject Type = CA with Path Length = 0 through a dedicated certificate template allows organizations to meet this requirement without introducing unnecessary restrictions at the CA level or affecting other certificate templates and dependent applications. 

The broader principle extends beyond Veeam. Applications requiring specialized certificate configurations should be managed through appropriately scoped templates, with clearly defined enrollment permissions, documented settings, and periodic reviews against vendor requirements. This approach minimizes unintended changes to the CA hierarchy, reduces the risk of certificate validation failures, and supports consistent PKI governance as the environment grows. 

Frequently Asked Questions 

Does Path Length = 0 stop my CA from issuing other CA certificates? 

No. Path Length = 0 is a property of the one certificate Veeam receives, not a setting on the issuing CA itself. The restriction lives in that certificate’s Basic Constraints extension. The CA keeps issuing unrestricted CA certificates through every other template; only certificates issued from the Veeam-specific template carry the Path Length = 0 constraint. 

What’s the difference between Offline CRL Signing and CRL Signing in Veeam’s Key Usage requirement? 

Nothing functional. Microsoft’s X509KeyUsageFlags enumeration defines XCN_CERT_OFFLINE_CRL_SIGN_KEY_USAGE and XCN_CERT_CRL_SIGN_KEY_USAGE at the same value, 0x2. Both names point to the identical cRLSign bit in the X.509 Key Usage extension. Checking CRL Signing in your certificate template already satisfies the Offline CRL Signing requirement; there is no second box to find. 

Can I use a certificate from a public CA to meet this requirement? 

No. Veeam’s documentation excludes certificates issued by public CAs, along with ECC and CNG certificates, from this certificate slot. The certificate must come from an internal Windows Server CA or equivalent, use an RSA key of at least 2048 bits, and specify key type Exchange rather than a CNG provider. 

Why can’t I request this certificate through the AD CS web enrollment pages? 

Duplicating the built-in Subordinate Certification Authority template on a current Windows Server CA produces a version 3 or 4 certificate template. Microsoft’s own documentation confirms that native AD CS web enrollment pages cannot offer version 3 templates for request. Use the Certificates MMC snap-in, certreq, or a certificate lifecycle management tool instead. 

Would changing CAPolicy.inf or the CA’s registry path length work just as well? 

It would produce a certificate with the right Basic Constraints value, but it changes behavior for every certificate the CA issues, not just Veeam’s. A CA-wide registry default or a re-keyed CA identity is broader, harder to reverse, and risks breaking any other workload on that CA that needs certificates capable of becoming further intermediate CAs.