000011672 - After applying build 522  the validity period and extensions included in certificates issued via AEP Proxy are NOT as expected

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000011672
Applies ToRSA Certificate Manager 6.8
Fedora Auto Enrollment Proxy (AEP)
Microsoft Windows Server 2003
IssueAfter applying build 522, the validity period and extensions included in certificates issued via AEP Proxy are NOT as expected
aep.xuda
CauseAEP 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.
ResolutionCompare 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
WorkaroundApplied build 522 to RSA Certificate Manager 6.8 build 517
NotesThe 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.
Legacy Article IDa62262

Attachments

    Outcomes