@Mark_Wonsil , has anyone come up with steps to fix this Mark?
This is the thread a bunch of people started:
Also see this thread. It’s not EKW, it’s Chrome which EKW uses.
1 Like
Thank you. Is there anything published anywhere about what people need to do to resolve this error?
Like an ABC 123 type document?
Step 1: do this
Step 2: do this
Step 3: chill
Not that I know of.
We have used the PowerShell script from the post above to create a new cert but are still working out distributing them. But to tell the truth, the more work we start to put into it, the more we’re looking at getting a trusted cert like Let’s Encrypt. Like many others, this is a challenge if the internal DNS uses a non-standard/non-authoritative domain like .local. You cannot create certs for those domains.
Mark, Taylor thank you for your help on this! very helpfull.
We’re getting this rolling now will let you know how it goes for us
The distanced approach that Epicor takes from this is what kills me though. I’m sure they are aware of it from a case standpoint.
Where are they at? We are manufacturing companies, some of us without any I.T. personnel.
At what point is it appropriate to expect Epicor to at least make a statement about what needs to be done instead of having us figure it out?
Is that asking too much @Mark_Wonsil ? You, @Samcox , me, and others might be able to root cause it and figure it out, but it’s gotta be at least something we can go to them to get some help on.
@Samcox did you open a case?
The Epicor answer may very well be, get a trusted cert. SaaS people aren’t experiencing this because they use Epicor’s cert. The problem isn’t as vast to Epicor as it is to us smaller shops getting by on self-signed certs. This problem will appear with non-Epicor web-based applications too. Sure, some guidance from Epicor would be nice, but it’s a platform problem at the moment and not directly with their software.
Do they still sell on prem licenses? I’m not going to debate cloud cause I agree about the direction. But if you’re going to sell and charge support for on prem instances, it’s your responsibility to live up to it.
I understand, but there are some foundational requirements and there’s the software. Should Epicor support SQL Server setup? Windows setup? I’m only suggesting that since Epicor didn’t write Chrome, we’re in a little gray area here. Yes, a working solution would be welcome, but if they start saying that the software now requires a trusted cert, there’s not a lot we could do about it. 
Hi guys, yeah we had a case raised so they was aware.
We have gotten the cert created and linked now and we are back up and running, thanks for your help on this guys
1 Like
Check here, as for the deployment of the cert we do through a GPO policy. All the steps should not take more than an hour to generate and deploy as long as you have an AD environment to deploy the GPO.
That’s right. Although, AD won’t work for mobile devices (EKW), other non-Windows tablets, or external services like Automation Studio, Azure Services (Application Proxy), etc.
Yes AD will not work with EKW, but I Believe EKW does not need the cert deployed to it. In my tests EKW worked just by using the certificate generated.
The deployment through GPO we did was mainly for Chrome and Executing Epicor functions from customizations.
As for the others we did not test since that is not part of our environment. But I agree, the best solution is to get a recognized CA signed certificate.
We have not been able to get our Intermecs to work. They stop working once Chrome updates to a certain version. After that, we get the incompatible message in the browser and the app won’t connect.
IT has had trouble importing the cert as well. Any hints or tricks would be greatly appreciated.
Do you have an idea of where your IT is getting stuck when importing the cert?
One thing to note on CN=your_domain.com, it should actually be CN=server_name.your_ad_domain.com (.com might be different in your setup, but it does have to be the fully qualified domain name for your server).
Maybe to make it easier for the import on the server side you could convert the .crt to a .pfx, that will have both the private key and certificate together.
openssl pkcs12 -inkey your_key.key -in your_cert.crt -export -out your_pfx.pfx
The just use IIS to import the certificate on the server, On IIS click on the Server, then Server Certificates, then Import.
After importing it should show up on the list under the site binding on https, just change the cert there and you are all done. In our case we are using Zebra units for EKW, we did not have to do anything else, as soon as we updated the certificate that we generated using the instructions in the link I posted it started working with no issues.
They can’t import the certificates into the device. It’s Android, so when we browse to the site using Chrome, it gives the certificate error. We USED to be able to accept the risk and import the cert but that is no longer an available link to activate. Using Android’s import cert function, it won’t accept the password used during the export. The cert does work in Windows though.
Ok, So the part of Importing the generated certificate to the Epicor App Server in windows did work?
We did not have to do anything on the device, the EKW app just accepted it as is with everything updated to the latest version. As for chrome it should give you some kind of error, when we first started having the issues chrome was giving the error that the Key Usages was invalid. Do you have an error code so we can help out? If the error is not visible then you will probably need to do a remote debug session to review.
OK, I got back with IT and this is where we are:
-
Desktop: Using Chrome with the new self-signed cert created with PowerShell AND imported into Trusted folder in the Certificate Snap-In works without any warnings or errors.
-
Android (Intermec): After deleting installed certs, EKW now works and no “Invalid Usage” or “Incompatible” errors. However, browsing to the site in Chrome works but with the non-trusted icon. We’ll try to load the cert again next week as he got called away.
I ran into a certificate issue the other day. And a long time in past (back in 2021) it turns out that the acme.sh shell script which is typically used in linux environments on a cron job use to renew certificates for let’s encrypt. If you weren’t paying attention then all of a sudden your website would go down, due to the fact that you certificate had expired. Don’t ask how I know. 
Here’s the link to the Let’s encrypt issue
So a couple of suggestions.
*It is possible to run your own certificate authority server internally to manage these types of scenarios.
For Android and handheld using a tool like SOTI, MS Intune or some other MDM that will allow you to manage certificates on all your handhelds.
This acme.sh issue may not even be relevant, but I thought I would mention it. I am by no means a certificate expert, but the biggest problem I see is that they get setup, forgotten and then they expire and people end up scrambling to fix the problems and how they got it working in the first place. Please ensure you document the process and put it in a safe place for when the inevitable happens.