[Ejbca-develop] EJBCA 6.3.1.1 Community - MS Guid does not get stored in certificate SAN OtherName

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

We are using EJBCA 6.3.1.1 Community (r21429).

We have discovered that, when creating a certificate using a Domain 
Controller CSR (containing an MS GUID in the OtherName field), the MS 
GUID does not get stored in the certitficate SAN - OtherName field. It 
does, however, get stored in the End Entity SAN - OtherName field.

For a Domain Controller certificate, the SAN - OtherName - DS Object 
GUID is necessary for replication, as stated in the Microsoft 
Requirements 
<https://support.microsoft.com/en-us/help/291010/requirements-for-domain-controller-certificates-from-a-third-party-ca>[0].

We mention that:

  * The DomainController Certificate Profile contains in the Other data
    - Subset of Subject Alt. Name - "Other Name", "DNS Name" and "MS
    GUID, Globally Unique Identifier"
  * The generated certificate does get the DNS Name in the SAN
  * The end entity contains the GUID field in the SAN - OtherName

In order to investigate, I have turned on TRACE logging on the EJBCA 
server and found out that (logs below contain <REDACTED> instead of 
actual values):

  * the MS Guid is passed correctly in the request payload -
    "[org.cesecore.certificates.certificateprofile.CertificateProfile]
    CertificateProfile: constructed DN or AltName:
    DNSNAME=<REDACTED>,GUID=<REDACTED>"
  * The MS Guid is parsed by the CertTools class - TRACE
    [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1)
     >getPartsFromDNInternal: dn:'DNSNAME=<REDACTED>,GUID=<REDACTED>',
    dnpart=guid, onlyReturnFirstMatch=false]
  * What is strange is that in the logs, there are multiple calls to the
    getCustomOids() call, and
      o two calls contain both the DNS name and the MS Guid
      o One call contains only the DNS name

12:40:39,335 TRACE [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1) 
 >getCustomOids: dn:'DNSNAME=<REDACTED>,GUID=<REDACTED>

12:40:39,336 TRACE [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1) 
<getCustomOids: resulting DN part=[]

12:40:39,357 TRACE [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1) 
 >getCustomOids: dn:'DNSNAME=<REDACTED>,GUID=<REDACTED>

12:40:39,357 TRACE [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1) 
<getCustomOids: resulting DN part=[]

12:40:39,367 TRACE [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1) 
 >getCustomOids: dn:'dNSName=<REDACTED>

12:40:39,367 TRACE [org.cesecore.util.CertTools] (http--0.0.0.0-8443-1) 
<getCustomOids: resulting DN part=[]

To conclude, it seems that somewhere in the code, a decision is made to 
skip the MS GUID from the logic, and that decision affects the 
generation of the certificate (as the MS Guid does get stored in the End 
Entity).

I tested in EJBCA 6.5.0.5 Community (using the test VM [1]) with a 
similar setup we have on the older version and could not replicate the 
problem - the MS GUID got stored in the generated certificate. Was this 
a known issue that got fixed? I could not find anything related in the 
EJBCA changelists or in your Jira database [2].

Thank you.

Regards,

Andrei

[0] 
https://support.microsoft.com/en-us/help/291010/requirements-for-domain-controller-certificates-from-a-third-party-ca

[1] https://www.ejbca.org/download.html#Virtual%20Machine%20for%20Testing
[2] https://jira.primekey.se/browse/ECA-992?jql=text%20~%20%22MS%20GUID%22

__

Andrei Epure

Software Engineer
Almetis