Self signed SSL cert being blocked by Chrome

Just a couple weeks ago I was able to access Epicor via https in Chrome. Since we have a self signed cert(we don’t have active directory) we’d always get a warning about the certificate but we could click Advanced and proceed(unsafe), but that seems to have stopped working. Oddly other browsers(Firefox, Edge, and Opera) to work… The error we are getting from Chrome is: ERR_SSL_KEY_USAGE_INCOMPATIBLE

What are best practices / recommendations? We could get a letsencrypt certificate installed but we’d have to change the domain name. If this is the recommended solution, what else would we need to update if the domain name of our application server were to change(so we can get a valid SSL cert that isn’t self signed)?

There are several discussions about this on the forum and the usual solution is:

And since cert lives are dropping quickly, it’s best to automate it.

Thanks Mark, we’ll look into getting a legitimate SSL cert in that case. Currently the domain we use on our LAN is not one we own(the equivalent of .home.apa). We’ll need to change the domain name of our application server to get a legitimate SSL certificate. What ramifications would that have - I’m thinking all client configs would need to be updated(eg epicor.home.arpa → epicor.legitdomain.com). I’m not sure what else though?

Well, I’m not a DNS expert but this is what I did for my dev machines:

As long as you’re not using Windows SSO, the App Server does not need to be on the domain, but yes, you would then update the .sysconfig files for the smart client in all the places where the old domain exists.

How did you generate your cert?
Here is an article, technically it suggests to delete the cache, but it is not what I am interested in - there is a description what keys are expected in the cert, does it correspond to what you have?

1 Like

@Mark_Wonsil you are awesome! Sorry my question was vague, in regards to Epicor do you know what Epicor specific changes would be needed if the domain of the application server changes. So as an example I see the sysconfig files would need to be updated for the clients. If we change the domain name and not the sysconfig files the clients won’t be able to access the application server. What I don’t know is what other changes would be needed. Any chance you know what else would need to be updated?

I would think one would also need to add a new endpoint with the new cert bound to it. This will have implications for extensions like Enterprise Search, Data Discovery, etc.

The only real way to know is to spin up a test system (VM if possible) with the new cert, get it working, then replicate it once you have it working.

1 Like

@Mark_Wonsil thank you so much, as usual great response and I very much appreciate that!

I’d love to set this up in a sandbox so we can do a proof of concept before touching production. We’re using VMs for Epicor application server and DB so I think that would be pretty easy to do!

1 Like

Hi Olga,

I ran into this issue in Kinetic on a non-domain joined environment and had used Epicor to create my original certificates. FYI, the certificates worked fine for the last few years and recently stopped functioning. I too ran across the post you’ve linked, but deleting the Local State file did not work in my case.

Please see Clint’s post (and my follow-up) for the details on generating a new certificate.

1 Like

I wrote:

it suggests to delete the cache, but it is not what I am interested in

My point was that cert does not contain required key usage, not deleting the cache.

You can create cert with powershell and it should work.

If you say that EAC creates cert incorrectly now, then report it.

1 Like

My memory sucks but I believe it might have been the Friendly Name key that was missing.

My apologies - I mistook your original post as trying to troubleshoot what may have gone wrong on the Epicor side and how to troubleshoot and/or correct the issue. Since I had the exact issue the OP posted, I wanted to post the background that led to the issue and the solution.

I’ll check to see how Epicor works the next time I install a current version of Epicor (the particular cert in my case was generated on a an early version of Kinetic), and if Epicor’s generated certificates no longer work, then I’ll submit it to support.

1 Like

I can confirm on 10.2.400 I see the same behavior as Chris. The EAC makes it really easy to generate and install a self signed certificate, unfortunately Chrome rejects it with an error of ERR_SSL_KEY_USAGE_INCOMPATIBLE. This is not a warning that the root authority can’t be verified and you can accept the risk and still visit the site. This is a hard stop in Chrome, I can’t find anyway to convince Chrome to let me visit the site. Other browsers accepted the cert… I didn’t report it as I expect Epicor’s response would be upgrade to a supported version of Epicor as this was fixed. Wearing my IT hat I 100% agree and don’t like the fact we’re not updating our ERP system, but as a small business I understand and respect ownership can’t justify the costs to upgrade and that they are willing to accept the risks.

I can also confirm using powershell to generate a new key does work, which is much cheaper than upgrading…

Chrome will accept once you install your generated self-signed cert into trusted root authorities on the local machine.

Probably you are not in those Chrome users that started getting this error.
Google updates small percentage of people, which is understandable, but make it hard to troubleshoot

I believe they are just not adding it to Trusted Root on the Local Machine they are using to access via Chrome browser.

Also, may need to restart the browser completely sometimes.

Nope fully up to date:

Still working :slight_smile:

I can’t explain this. For some people it works, for others - does not. Yet it depends on Chrome you have. Maybe we need to google the answer :slight_smile:

Many large web-based companies do a roll-out based on groups (A/B, rings, etc.). If one is not in a leading group or ring, the update will not appear even if we check for updates.

1 Like

Mine is the same and I saw this error with certs created in IIS.
Version 121.0.6167.161 (Official Build) (64-bit)

Maybe it is not a version per se but some flag switched on/off