Cross-Certification for Non-Windows Clients

Question

Still trying to get more information on getting my SHA256 root CA certificate signed by my SHA1 root CA (temporarily), and having non-Windows entities recognize that:
Creating Cross-Certification between two root CA's within the same organization (one hierarchy is all SHA1 and the other is all SHA256) and distributing the CrossCA certificate is painless enough for Forest members because it gets published to
AD and from their comes down to the Forest member certificates store (Trusted Intermediary).  But what is the best way to get non-Windows end entities to also recognize the CrossCA certificate?  The RFC (http://tools.ietf.org/html/rfc5280#section-4.2.2.1)
states you can configure the AIA extension to point to a collection of certificates, but then that means (unless I am missing something) I need to modify the AIA extensions configuration on my SHA256 root CA to point to the PKCS7 container on my http location,
then issue my SHA256 SubCA certificates to my subordinate CA's.  So this way when my SHA256 subordinate CA's issue end entity certificates to non-Windows entities the chain of trust will go back to my SHA1 root CA.
Both hierarchies are 2-tier.
End Entity cert from SHA256 Subordinate CA --> http location specifying the location of the SHA256 SubCA .crt --> http location specifying the location of the exported Cross-Certification certificate in PKCS7 format (which contains the
SHA256 root CA certificate and the SHA1 root CA certificate).
Does this seem like the correct configuration?  If so, how easy will it be to remove this configuration when the cutover is complete?  If this is all correct then I assume the only way to remove this configuration is to modify the AIA extension
of the SHA256 root CA and then issue new SubCA certificates to my SHA256 subordinates.

Answer 1

Elke,
Thank you for the information.  I defintely have some other options to consider now.
One odd thing I noticed in my lab is my setup appears to work differently than you described.  In my lab I have a crossCA certificate which was published automatically into AD when it was issued.  Since that has happened even when issuing
new certificates to end entities that are aware of the new SHA256 CA's (and Trust them), all certificates still chain back to my SHA1 root CA.  They don't take the short route anymore.
And because of the above behavior I ran a quick test:
- I installed a Windows 7 machine and never joined it to AD (kept it in a workgroup)
- I manually imported the SHA1 root CA certificate into its certificates store
- Then I accessed a web site running on a Windows web server which had an SSL certificate from one of the new SHA256 Subordinate CA's (and was part of the domain so it trusted the new SHA256 CA's).
The result was the Windows 7 machine trusted the certificate just fine.
When I looked at the certificate through IE on that Windows 7 machine, it showed the SSL certificate chaining back to my SHA1 root CA which I manually imported earlier, so it was trusted.
Perhaps this is where setting constraints in the policy.inf file come into play...not 100% sure.
Anyway, for the reasons you pointed out to me and the fact that anchoring my SHA256 environment with a SHA1 CA isn't really recommended, I am going to explore some other ways to get this done.
Thank you.