Hi All,
We have a problem with our warehouse guns which is being looked into but in the mean time we are looking for a manual process, is there any way to pick orders without the EMW system?
Is it the same problem everyone else is having with invalid URL?
Hi Taylor, yes it is.
Have you managed a workaround/resolution at all?
@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.