Yellow warning triangle on "Basic Constraints" section of my Enterprise CA certificate

Could you provide the full detail, is the root CA public in the GPO publishing it as trusted root.

Can you provide more detail on everything included in the error?

Which version of windows did you upgrade from?

Hi Arnlod,

There are no GPO that are publishing the root CA. Its manually installed in the local machine certificate store on machines as needed. It is installed in the Trusted Root and Trusted Publisher folders.

The previous domain controller and CA was Win 2003 R2.

There is no error per-say that I can elaborate on. Vcenter, SPS, and other internal web servers all seem to be functioning normally with this root CA.  
There exchange issue that I eluded to in my original post happens when opening outlook 2013. A warning pops up outlining "The name on the security certificate is invalid or does not match the name of the site". It's odd because the internally signed SAN certificate in use has everything from external/internal exchange related addresses to even the domain controller addresses in its alternate DNS field which is what lead me to look into this odd attribute on the root CA cert. I have a hunch my exchange issue will clear up once I get this sorted, so I'll save the details on that for another later query.

Anything else I can provide relating to the CA cert that may be of help?

What is the hostname that outlook uses, it might be using the exchange path, which is the issue.
The error should tell you the name being accessed.
You might be pushing just exchange and not exchange.locala.local

Outlook accesses exchange using its standard fqdn, which is also what all the InternalURL variables in the various XYZVirtualDirectories are set to: exchange1.domain.com (/XYZ)

Again, its not an error per-say, its just a warning that users have to push past 1 time when they open outlook, something (thanks to my predecessor) they are more than fine with doing.

I'd really like to wind back to the focus of my question which is,  "What could cause / How do I correct the yellow warning sign on the "Basic Constraints" field of my root certificate. This is visible not only in exchange, but on any server or client machine that I view the certificate on, and I'd really like to correct it.

Hi Arnold,

Thank you for the help so far.
Over the weekend I tried method 1 and method 4 (recreated SAN with domain.com and local pc regedit) outlined in the link provided but the warning prompt still pops up when outlook is launched.
Again, I'd like to correct the warning in the Enterprise Root CA certificate before going too deep in the exchange / outlook investigation. Do you have any other ideas on what I can look for or modify in order to correct the warning section of the CA cert?

You need to include autodiscover in the SAN certificate.

The issue is that the certificate used in the auto discover connection is either a self signed or it is missing  the one name.  One of the options deals with disabling the certificate verification scheme for the autodiscover process.  At times, registry changes require a reboot to take effect.

autodiscover.domain.com is indeed included in the SAN, which is signed by the domain enterprise CA cert that I'm attempting to fix.

I'll try rebooting my client pc in a bit and see if the suppression regedits take effect.

No change after the reboot I'm afraid

What San names does your certificate have?
Double check the hostname in the GPO you are pushing to user for outlook auto config.

Are you able within outlook to look at the certificate for which this error shows in an effort to figure out whether you missed a component/service to which to attach the ca signed San certificate.

Hi Arnold,

My apologies on the lapse. Its been a busy week of fire-fighting.
The SAN names are as follows
DNS Name=mail.domain.com
DNS Name=domain.com
DNS Name=autodiscover.domain.com
DNS Name=webmail.domain.com
DNS Name=mob1.domain.com
DNS Name=mob2.domain.com
DNS Name=exchange1.domain.com
DNS Name=exchange2.domain.com
DNS Name=exchange3.domain.com
DNS Name=DC2.domain.com   (the box with the CA role)
DNS Name=DC2-CA.domain.com  (the name of the CA, added for testing)

Again, we aren't publishing the root CA cert via a GPO yet, though I likely will once I get a stable configuration set for this  worked out on my machine.

I wasn't sure how to look within outlook and and verify certificate statuses, but while using the Test E-mail Autoconfiguration I did find a few potentially interesting things. In the tool (which is accessed by holding Ctrl then right clicking the Outlook icon on the systems tray) I did a test with only the "Use Autodiscover" box selected.
What I noticed was that the early steps of the test results all printed servername.domain.com for early interactions, but switches to mob2.domain.com for the last half and outlines that the principal name of the certificate is mob2.domian.com . Mob2 is an external address that connects through an ISA 2006 box and it has its own 3rd party signed cert.
Wondering why the target server name would switch from the machine name to its external alias let me to run
Get-AutodiscoverVirtualDirectory | fl *URL on my exchange box where I found that neither the InternalURL nor ExternalURL field were set. More head scratching ensued.

I probably jumping the gun a lot here, but in line with your hunch that this is autodiscover related, could any of this be having an impact in your opinion?

Though I stumbled across the solution on my own, Arnold's faith that the problem was autodiscover related is was compelled me to keep searching in that direction and eventually find my solution.