After applying build 522 the validity period and extensions included in certificates issued via AEP Proxy are NOT as expected
3 years ago
Originally Published: 2013-08-19
Article Number
000044131
Applies To
RSA Certificate Manager 6.8
Fedora Auto Enrollment Proxy (AEP)
Microsoft Windows Server 2003
Issue
After applying build 522, the validity period and extensions included in certificates issued via AEP Proxy are NOT as expected
aep.xuda
Cause
AEP page, aep.xuda, in RSA Certificate Manager 6.8 build 519 (and in later builds) has been updated to resolve some issues. (For details about changes/fixes to AEP related functionality, see RSA Certificate Manager 6.8 build 522 Readme.)  This page, aep.xuda, in most scenarios requires manual changes specific to each deployment. Once build 522 was applied, the customized aep.xuda was replaced with default/updated version from build 522 and hence the customizations were lost.
Resolution
Compare the customized RSA_CM/WebServer/admin-server/ca/aep.xuda from the previously deployed build (build 517 in this scenario), with the one from recently applied build (build 522 in this scenario) to find the differences.  In most cases, values for jurisdiction id's (domainid), extension profile id's (PRO), and/or request OID's (myoid) are updated in aep.xuda and those changes will manually need to be made to aep.xuda AFTER applying the latest build.  Update aep.xuda, after applying the latest build, as per your deployment (to make it similar to the original one).

Also inspect differences in the following files and update those as well if required:

RSA_CM/WebServer/admin-server/ca/aep/aep-auto-add-request.xuda
RSA_CM/WebServer/admin-server/ca/aep/aep-renew-certificate.xuda
Workaround
Applied build 522 to RSA Certificate Manager 6.8 build 517
Notes
The following new parameter was added to aep.xuda in build 520 (and also shows up in later builds):

  [@useAD='1']

In build 517 (or previous to build 520), when requesting certificates through AEP, the subject of issued cert was taken from Active Directory. In build 520 (and later), the subject DN can be taken from PKCS#10 request. Set useAD flag to 1 (in build 520 or later) to keep the old behavior (use subject DN from AD). Set useAD flag to 0 (in build 520 or later) to use subject DN from PKCS#10.  The default behavior remains un changed in newer builds.
An issue around TTL was fixed in build 519.  See the following solution for more details:

When issuing a cert via AEP the validity period is always set to 1 year no matter the validity specified in the extension profile/Jurisdiction.
The following new parameter was added to aep-auto-add-request.xuda in build 520 (and also shows up in later builds):

NO_TTL

If NO_TTL flag is set, the value set for directive TTL is ignored and the validity period is taken from jurisdiction configuration when requesting certificates through AEP.

Related Articles

Trending Articles

Don't see what you're looking for?