D
Dapperville Inn
I am going through final stages of MCSA prep and with so many labs landing in a configuration where self-signed certificates are produced--I wonder why, since an enterprise CA has been deployed, certificates aren't produced by the issuing CA?
I started investigating the feasibility of producing templates, which are required with Enterprise Certificate Authorities (CAs), which can provision certificate requests which will meet the configuration requirements that can be deduced from reviewing the details of the self-signed certificates (the so-called reverse engineering approach) resulting from so many of the Windows Feature installations.
My primary point of reference, henceforth referred to as original point of reference (OPOR), being the original self-signed certificate, in this example one produced from the default configuration of DirectAccess after a fresh feature install for VPN. See the screenshot:
Obvious things to consider:
- I can examine the details of the certificate and some of the configuration parameters are obvious and easy to reproduce when trying to provision a template that can issue an appropriately configured template for a new request, employing the Enterprise CA infrastructure.
What further becomes obvious is once you try to provision a template, is the myriad of configuration options with similar terminology. And it then becomes a guessing game (process of elimination trial) but that can be really complicated since I would have to issue several different certificates, with different template configurations (potentially), and then try installing them to see if they're sufficiently-suitable replacements for the self-signed originals. You can see why I'd rather just get my information correct before I start such a process, so I can just do it right the first time--hopefully.
So now I wonder, how--if possible, to reverse engineer certificates in such a case scenario.
Using the earlier screen shot, I have tried to first produce a new template, which seems to only be possible in the CA Mgmt Gui (certsrv.msc) by selecting the Manage option from the context menu of the Certificate Templates node, which brings us to our next question:
As far as I know, the only way to even begin to get a custom template is to try duplicating an existing template and configuring new parameters from there, however this can prove problematic since duplicate templates only provide subsets of the features of the original template--bringing us to our next problem:
Here are some more screenshots, so you can see my problems.
My first point of consideration, as evidenced by the notes (circled points of attention) in the screenshots, was to try to find a certificate template with an Intended Purpose of <All> like the original. There are many configuration points where a "purpose" can be configured, I am completely bewildered and could only hazard a guess as to which is the relevant setting to replicate the configuration of the original.
One of the first things I tried was to identify which templates might match that setting. I first went to the dialog box which pops up when you right-click the Certificate Templates node in the CA mgmt snap-in and select "New > Certificate Template To Issue."
This is primarily to further the discussion. I found the circled items, in addition to a hidden (from view of the screenshot), entry for the Subordinate Certificate Authority, which also happened to reflect a similar value of <All> for Intended Purpose.
I began my efforts to produce new templates I might be able to configure to meet the needs of the DirectAccess-RADIUS-Encrypt... self-signed cert.
I chose the Subordinate Certificate Authority next and quickly realized that many of the features I would need weren't there to be found, because the template is there to mainly provision subordinate CAs--duuuuuh. But I tried, right?
So then I considered, which of the available templates, might meet the needs of the original cert. It says "encrypt" in the description, so I figured the primary purpose was for encryption so I started going through the list of existing templates and landed on the IPSEC template.
This is where it gets loopy. There are gonna be many circular references, I hope I can keep everything orderly.
Just exploring some of the more obvious things--selecting an encryption standard (RSA - 1024-bit), so let's review that first. Bear in mind, this is from the IPSEC template and the first screenshot reflects the default configuration settings of the Cryptography tab.
I see that it will be simple to match the settings for an RSA cryptography service provider (CSP) and a corresponding key length; next question:
You can try a different Provider Category setting, but the only alternative seems to be for Key Archival (key storage), which does produce the desired result of manually specifying the hash algorithm, which I am presuming is what controls the effective settings in the original, self-signed certificate serving as the original point of reference (OPOR).
Here's the evidence.
Since we're at a point to discuss providers as well:
I have yet to find any authoritative information on which providers to use under given circumstances. I imagine that somebody should tell me; that somebody being the application/service with installation instructions that might outline certificate requirements. But how often do we find that within the wheelhouse of Microsoft Features/Services and corresponding configuration/installation documentation??
That seems fairly straightforward for the sake of discussion, although I haven't tested it myself, since I have many points of confusion regarding intended purpose, the original setting I set out to match. More on that here:
This was the first example where I found a possible candidate setting, but I'm not sold since there is not an actual <All> setting, however we know within PKI, all certs and intended purposes can be shoehorned into two categories of application--either signature or encryption. So I cannot rule it out as a candidate since both of those categories can be found here.
The next and last place I found a possible candidate setting, was under Extensions tab (still same dialog box for duplicate template) > "Extensions included in this template" section > Application Policies entry > then selecting Edit...
Could that be the candidate that would produce the <All> value of the OPOR, self-signed certificate?
If anybody has any channels to high-speed PKI admins/gurus that could give guidance/insight to how this type of "reverse engineering" operation should be done, if possible. I would be eternally grateful.
There is a lot of information but it all seems to just scratch the surface and I'm looking to plant my feet and dig in for the good fight--the 'good admin' fight.
I'd love to know how to reverse engineer one of those self-signed certs, which are so abundant after feature installs in Windows Server, and how to create templates in Enterprise-CA environments, that meet the needs of services. If this means diving into how to find the original certificate requirements for said features/services--I'm game.
Thanks, in advance!
Dapp
Continue reading...
I started investigating the feasibility of producing templates, which are required with Enterprise Certificate Authorities (CAs), which can provision certificate requests which will meet the configuration requirements that can be deduced from reviewing the details of the self-signed certificates (the so-called reverse engineering approach) resulting from so many of the Windows Feature installations.
My primary point of reference, henceforth referred to as original point of reference (OPOR), being the original self-signed certificate, in this example one produced from the default configuration of DirectAccess after a fresh feature install for VPN. See the screenshot:
Obvious things to consider:
- I can examine the details of the certificate and some of the configuration parameters are obvious and easy to reproduce when trying to provision a template that can issue an appropriately configured template for a new request, employing the Enterprise CA infrastructure.
What further becomes obvious is once you try to provision a template, is the myriad of configuration options with similar terminology. And it then becomes a guessing game (process of elimination trial) but that can be really complicated since I would have to issue several different certificates, with different template configurations (potentially), and then try installing them to see if they're sufficiently-suitable replacements for the self-signed originals. You can see why I'd rather just get my information correct before I start such a process, so I can just do it right the first time--hopefully.
So now I wonder, how--if possible, to reverse engineer certificates in such a case scenario.
Using the earlier screen shot, I have tried to first produce a new template, which seems to only be possible in the CA Mgmt Gui (certsrv.msc) by selecting the Manage option from the context menu of the Certificate Templates node, which brings us to our next question:
- Is it possible to produce a template entirely from scratch?
As far as I know, the only way to even begin to get a custom template is to try duplicating an existing template and configuring new parameters from there, however this can prove problematic since duplicate templates only provide subsets of the features of the original template--bringing us to our next problem:
- How do we know which templates can sufficiently provide the correct set of configuration parameters needed to provision an enterprise-issued certificate as a replacement for a self-signed certificate?
Here are some more screenshots, so you can see my problems.
My first point of consideration, as evidenced by the notes (circled points of attention) in the screenshots, was to try to find a certificate template with an Intended Purpose of <All> like the original. There are many configuration points where a "purpose" can be configured, I am completely bewildered and could only hazard a guess as to which is the relevant setting to replicate the configuration of the original.
One of the first things I tried was to identify which templates might match that setting. I first went to the dialog box which pops up when you right-click the Certificate Templates node in the CA mgmt snap-in and select "New > Certificate Template To Issue."
This is primarily to further the discussion. I found the circled items, in addition to a hidden (from view of the screenshot), entry for the Subordinate Certificate Authority, which also happened to reflect a similar value of <All> for Intended Purpose.
I began my efforts to produce new templates I might be able to configure to meet the needs of the DirectAccess-RADIUS-Encrypt... self-signed cert.
I chose the Subordinate Certificate Authority next and quickly realized that many of the features I would need weren't there to be found, because the template is there to mainly provision subordinate CAs--duuuuuh. But I tried, right?
So then I considered, which of the available templates, might meet the needs of the original cert. It says "encrypt" in the description, so I figured the primary purpose was for encryption so I started going through the list of existing templates and landed on the IPSEC template.
This is where it gets loopy. There are gonna be many circular references, I hope I can keep everything orderly.
Just exploring some of the more obvious things--selecting an encryption standard (RSA - 1024-bit), so let's review that first. Bear in mind, this is from the IPSEC template and the first screenshot reflects the default configuration settings of the Cryptography tab.
I see that it will be simple to match the settings for an RSA cryptography service provider (CSP) and a corresponding key length; next question:
- But how might I match the hash algorithm since it's grayed out and cannot be modified?
You can try a different Provider Category setting, but the only alternative seems to be for Key Archival (key storage), which does produce the desired result of manually specifying the hash algorithm, which I am presuming is what controls the effective settings in the original, self-signed certificate serving as the original point of reference (OPOR).
- Is that a correct assumption/presumption?
Here's the evidence.
Since we're at a point to discuss providers as well:
- how do we know which providers will be sufficient to provision a replacement for the OPOR?? E.g., I know that when dealing with TLS/SSL, SChannel providers are designed for that but can other providers work too?
I have yet to find any authoritative information on which providers to use under given circumstances. I imagine that somebody should tell me; that somebody being the application/service with installation instructions that might outline certificate requirements. But how often do we find that within the wheelhouse of Microsoft Features/Services and corresponding configuration/installation documentation??
That seems fairly straightforward for the sake of discussion, although I haven't tested it myself, since I have many points of confusion regarding intended purpose, the original setting I set out to match. More on that here:
This was the first example where I found a possible candidate setting, but I'm not sold since there is not an actual <All> setting, however we know within PKI, all certs and intended purposes can be shoehorned into two categories of application--either signature or encryption. So I cannot rule it out as a candidate since both of those categories can be found here.
The next and last place I found a possible candidate setting, was under Extensions tab (still same dialog box for duplicate template) > "Extensions included in this template" section > Application Policies entry > then selecting Edit...
Could that be the candidate that would produce the <All> value of the OPOR, self-signed certificate?
If anybody has any channels to high-speed PKI admins/gurus that could give guidance/insight to how this type of "reverse engineering" operation should be done, if possible. I would be eternally grateful.
There is a lot of information but it all seems to just scratch the surface and I'm looking to plant my feet and dig in for the good fight--the 'good admin' fight.
I'd love to know how to reverse engineer one of those self-signed certs, which are so abundant after feature installs in Windows Server, and how to create templates in Enterprise-CA environments, that meet the needs of services. If this means diving into how to find the original certificate requirements for said features/services--I'm game.
Thanks, in advance!
Dapp
Continue reading...