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

We have our enterprise certificate authority setup up on one of our DCs. The server is running Win Server 2012 R2, and the CA and its templates were migrated to the machine during a DC upgrade project.
The CA is used periodically to make certs for internal systems, but while troubleshooting an issue with exchange 2010 I noticed that the root ca certificate has a little yellow triangle with an exclamation mark next to the "Basic Constraints" field.   The data in the field is

Subject Type=CA
Path Length Constraint=None

Aside from an extra carriage return after the second line, the data appears normal. Anyone know how to fix this before I renew the CA certificate on my DC?
LVL 1
sloutzAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

arnoldCommented:
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?
0
sloutzAuthor Commented:
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?
0
arnoldCommented:
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
0
Introducing the "443 Security Simplified" Podcast

This new podcast puts you inside the minds of leading white-hat hackers and security researchers. Hosts Marc Laliberte and Corey Nachreiner turn complex security concepts into easily understood and actionable insights on the latest cyber security headlines and trends.

sloutzAuthor Commented:
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.
0
arnoldCommented:
Double check as the service to which outlook is connection is encountering the  self-signed certificate versus the san cert you think is in use.

You missed the autodiscover ...
https://support.microsoft.com/en-us/kb/2783881
0
sloutzAuthor Commented:
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?
0
arnoldCommented:
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.
0
sloutzAuthor Commented:
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.
0
sloutzAuthor Commented:
No change after the reboot I'm afraid
0
arnoldCommented:
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.
0
sloutzAuthor Commented:
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?
0
sloutzAuthor Commented:
I think I've resolved the source of the outlook certificate warning after reading through this article
https://exchangemaster.wordpress.com/2013/05/07/new-behavior-in-outlook-2013-causing-certificate-errors-in-some-environments/

In short, due to the way autodiscover works in 2013, one of its simultaneous queries was aiming at https://domian.com/autodiscover/autodiscover.xml which inside my network resolves to my domain controller and not an exchange box. Since the domain controller is also the CA, port 443 was open to connections, but no certificate was bound to the port in IIS. All I had to do was bind the SAN cert to the port on my DC and the outlook pop-up warning went away.

Though the outlook pop-up warning wasn't the problem outlined in the subject of this thread, it was the higher-level problem I was looking to resolve, so I am going to close out this thread.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sloutzAuthor Commented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SSL / HTTPS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.