fix: Move Microsoft TLS ECC and RSA Root G2 certs to roots section

[srunde3]

These certificates sign other certificates listed in the "subordinates" section, and are correctly listed as signing those subordinates in the "certificate authority chains" section.

It's important that these are properly listed as root certificates. These certificates do not ship in the default bundle on some systems and therefore need to be explicitly passed as "roots" whenever their subordinates are validated.

[prmerger-automator]

@srunde3 : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit fd5c078:

✅ Validation status: passed

File	Status	Preview URL	Details
articles/security/fundamentals/azure-certificate-authority-details.md	✅Succeeded

For more details, please refer to the build report.

[v-regandowner]

@shlipsey3

Can you review the proposed changes?

IMPORTANT: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[alnvdl-work]

As a side-note: the links to these certificates direct us to caissuers.microsoft.com, which in both Chrome and Firefox trigger net::ERR_CERT_COMMON_NAME_INVALID/SSL_ERROR_BAD_CERT_DOMAIN errors, requiring bypassing TLS cert verification. That should likely be fixed to guarantee safe provenance of these root certificates.

[kbracken-msft]

A certificate’s name does not define its role in path validation. A root certificate is, by definition, self‑signed and sits at the top of a PKI hierarchy. A cross‑certified "root" certificate is not self‑signed. Rather, it is issued by a different CA in order to create a certification path between independent PKIs.

Because it has an issuer, it is subordinate in the certification path and is validated like any other CA certificate during chain building. While the Subject Name of these certificates may contain the word "Root", their role in validation is that of a subordinate CA certificate, not a root.

They are presented as subordinate CAs for a reason, because that is what they are. As subordinate CAs, they are presented to clients in the TLS handshake, allowing clients to build a validation path to the issuing CA’s trust anchor (the DigiCert Global Root G2 or G3).

[shlipsey3]

No change. #please-close