Security

I'm having an interesting problem with OnBoarding, trying to pass CSR's to an MSFT AD Certificate Services CA.  The onboarding workflow does fine if I use the CA resident in the CP instance.  But when I configure for the MSFT CA, this error occurs:

 

Active Directory Certificate Services did not issue a certificate: Error returned by server: Your Request Id is 0. The disposition message is "Error Parsing Request ASN1 bad tag value met. 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)

 

I pulled the CSR out of a frame capture, collected on the MSFT CA.  After parsing with openssl asn1parse, most everything looks fine.  The only thing that concerns me is the requested SAN value, containing all of the 'mdps' attributes...as in:

 

'subject_alt' => array (
'mdpsDeviceType' => 'iOS',
'mdpsDeviceName' => 'iOS',
'mdpsDeviceUdid' => 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
'mdpsDeviceImei' => 'XX XXXXXX XXXXXX X',
'mdpsProductName' => 'iPad3,5',
'mdpsProductVersion' => '12H76',
'mdpsUserName' => '8021x@int.MYDOMAIN.net',
'mdpsEmailAddress' => '8021x@int.MYDOMAIN.net',
),

 

Knowing how picky AD CS can be about how SAN values are included in a CSR or appended to a CSR upon request, I wonder if some registry tweak or schema extension needs to occur to support these OIDs in the CSR.

 

If anyone has seen that 'CRYPT_E_ASN1_BADTAG' error or can lend any insight, I'd appreciate the help very much.  

 

Thanks.

I would double check your settings against this doc. It sounds like it might be a permissions issue.

https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=13757

Hmm. What permissions settings specifically do you have in mind? Security on the certificate template on the CA? Usually the error thrown if the requester is denied access to the template is 'Denied by policy module'. But maybe you're referring to some other permission setting?

As an additional warning from a security and trust standpoint:

There are only few situations where you would want to retrieve your Onboard certificates from your Active Directory Certificates Services.

 

ClearPass has a built-in Certificate Authority that is completely separated from your Enterprise PKI, so certificates that people pull from Onboard are only valid to authenticate to the network. There is no other (unintended) trust possible.

Onboard has been designed to put the bar as low as possible to get certificates; a solid full PKI has in general very strict and controlled procedures around certificate issuing. In most situations using Onboard to pull certificates from ADCS undermines those controls.

A reason to use ADCS is if you explicitly want full enterprise trust for any certificate that has been generated through Onboard, and accept the risk of loose controlled certificate generation.

 

In almost any other condition, keeping the Onboard Certificates separated from your Microsoft PKI is a safe and better choice. That things are technically possible is not necessarily  a good reason to do things in a certain way.

 

Please work with the security folks in your organization and check if this is really what you want, all risks of integrating are reviewed and explicitly accepted, before integrating.

Thanks for the PKI thoughts hrobers. I'm sure we could have a lengthy discussion about the additional administrative burden of standing up & managing a 2nd, parallel PKI in an organization where one might already exist. But that's not my purpose here.

This is a lab environment in which I need to be able to reproduce whatever configuration a potential customer might have deployed. Quite literally just b/c it's technically possibly in CP, I need to be able to test against it.

Thank you for your insight though.

I have just managed to get this working in my lab environment.  I took some doing, but I got there in the end.

 

What template are you using in AD?

 

In my setup I have CP as a subordinate to the Root.  I see the certs being generated (User template) and they are saved in CP as well.  If you don't see the certs being generated, it is most likely a permissions thing.  Make sure the user has rights to 'enroll' for that template.

 

There is nothing to differentiate the different certs for the same user apart from the serial no.  I'm curious to know how to get some of the MDPS fields added to the cert....but that may be the topic of a new thread.

> What template are you using in AD?

 

I’ve tried User, a custom User template that I already had, and a new template based off the User template.  Same error each time on the CA.

> In my setup I have CP as a subordinate to the Root.

 

I have the same.

> I see the certs being generated (User template) and they are saved in CP as well. If you don't see the certs being generated, it is most likely a permissions thing. Make sure the user has rights to 'enroll' for that template.

 

Yup, each one I tried has ‘Enroll’ Security permission enabled at least for the necessary user/group…in my case ‘Domain Users’.  Typically, the error on the CA with bad permissions is ‘Denied by Policy Module’.

> There is nothing to differentiate the different certs for the same user apart from the serial no. I'm curious to know how to get some of the MDPS fields added to the cert....but that may be the topic of a new thread.

 

Interesting. I see all of the MDPS fields in the SAN of the CSR when I extract the CSR form the packet capture. I’m wondering if that might be what’s throwing the 'ASN1 bad tag value met. 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)’?

Sounds like I might need to engage Microsoft for this...

 

It's worth noting that I have an Aruba support case open for this issue as well.  No reply yet from Aruba.  I'll post updates here as well as I get them.

I can't see the CSR going to AD cause I am using https.  I remember a long while ago that I had to enable the certsrcv page to use https only.

 

Is yours setup for http or https?

I'm using HTTP only.

 

If you have access to the private key, you could decrypt the trace but that's a lot of effort.

 

I might do some CSR comparison between what CP sends and a typical, successful web enrollment + submitted CSR.

 

We'll see.

 

Thanks for thinking about this with me though.  I appreciate it.

Turns out the root of my problem was the 'Key Type' configured in the Provisioning Settings.

 

'Created by server' yields this parsing request error / ASN1 bad tag value.

 

'Created by client' yields successful certificate creation by the MSFT Windows CA.

 

In the end, pretty simple solution.