Cross-Certification for Non-Windows Clients


still trying more information on getting sha256 root ca certificate signed sha1 root ca (temporarily), , having non-windows entities recognize that:

creating cross-certification between 2 root ca's within same organization (one hierarchy sha1 , other sha256) and distributing crossca certificate painless enough forest members because gets published ad , comes down forest member certificates store (trusted intermediary).  best way get non-windows end entities recognize crossca certificate?  rfc (http://tools.ietf.org/html/rfc5280#section-4.2.2.1) states can configure aia extension point collection of certificates, means (unless missing something) need modify aia extensions configuration on sha256 root ca point pkcs7 container on http location, issue sha256 subca certificates subordinate ca's.  way when sha256 subordinate ca's issue end entity certificates non-windows entities the chain of trust go sha1 root ca.

both hierarchies 2-tier.

end entity cert sha256 subordinate ca --> http location specifying location of the sha256 subca .crt --> http location specifying location of the exported cross-certification certificate in pkcs7 format (which contains sha256 root ca certificate , sha1 root ca certificate).

does seem correct configuration?  if so, how easy remove configuration when cutover complete?  if correct assume way remove configuration modify aia extension of sha256 root ca , issue new subca certificates sha256 subordinates.

as stated correctly aia url pointing cross ca certificate 1 embedded in certificates of ca subordinate (cross-certified) sha256 ca. certificate common either certificate chain (to short chain w/o cross-certificate , cross-certified one). if http url can point specific file - client can see , use new chain. windows clients should pick shorter chain though (not including cross-certificate) trust sha256 ca's root ca certificate. however, platform / application can apply different logic - prepared different apps. trust both root cas pick 1 chain or other.

make sure application in question check aia urls non-mandatory extension, , (or has been) not common in non-microsoft world. if ssl certificates - here chain distributed part of handshake. not need rely on aia, need make sure web servers send new subordinate ca certificate. example, windows web server having access short chain ending in sha256 root not send cross-certificate , java clients see incomplete chain (i had once encountered issue in scenario bit similar yours).

elke


Windows Server  >  Security



Comments

Popular posts from this blog

DCOM received error "2147746132" from...

ADFS 3.0 Event ID 4625 | An Error occurred During Logon | Status: 0xC000035B

DFSR RPC replication errors 5014 1726 with large files over VPN