I am currently struggling with an Epicor server deployment because I cannot get the Epicor server to “behave” after selecting an SSL certificate issued by GoDaddy (details purposefully left out, unless you reeeeaaaaalllly want to know).
My IT manager opened a case with EpicCare and was summarily told —
This isn’t something Technical Support can assist with. We have a Professional Services team that can help you with getting this outside certificate to work on your servers since it involves your network/IIS/Security setup.
The new install guide was also provided in the case history for us to review (we already have a copy of this, for obvious reasons). However, selecting an “existing certificate”, or a self-signed certificate is noted in the guide as part of the general setup and is not something identified as requiring Epicor Professional Services to implement:
(starting on page 42)
5.In the SSL Certificate Options dialog, select one of the following options, based on your requirements:
• Pick an existing SSL Certificate.
When you select this option, the Windows Security - Select a Certificate dialog opens and displays the available certificates. You can click More choices to view all available certificates. Select the certificate you want to use for Epicor Server and click OK. The SSL certificate you pick must have a Friendly Name assigned so that the Epicor ERP servercould recognize it. For information on how to verify and assign a Friendly Name to a certificate, review the Troubleshooting section in the System Administration Guide or the Epicor ERP 10.2 Installation Guide.
• Generate a new Self Signed Certificate.
Shouldn’t assistance with errors in this part of the installation process be handled by EpicCare, as it is one of the options listed in the new installation guide?
In my layman opinion:
This seems like it should be a very common and simple aspect of the Epicor server deployment process to resolve.
We can’t be the only customer site in the “EpicSphere” who has ever tried to deploy with an existing SSL issued by GoDaddy (or other SSL issuer)
It’s listed in the new installation guide and is not a deployment configuration that we’re “experimenting with”, or Frankensteining together under the direction of Joe Internet from some obscure forum. It’s – in – the – guide.
Brand-new, immediate deployment of 10.2.700.0; uplifted to v10.2.700.8
No extensions have been installed
Existing SSL certificate issued by GoDaddy
Certificate installed in the “Personal” store of the local server
Certificate “friendly name” changed from “GoDaddy” to “atest1.[domain name].com”, in line with our domain.
We had also experienced “UserFile.svc” errors that, upon checking the server’s Event Log, we discovered x509 certificate errors that forced us to modify the IIS application’s “web.config” file to identify the GoDaddy certificate by thumbprint value.
I had a recent thread topic opened for, essentially, the same issue – which was remedied for the specific problem I was having – but I believe this issue exists in a more broader sense (that I wasn’t aware of at the time), which is why I’m starting a new thread topic on it here.
General Behavior:
Once the deployment finishes, the EAC automatically tries to connect to the newly deployed E10 server instance. When this happens, I receive a “DNS Endpoint Identity” error (see below, marked in red):
We are purposefully NOT configuring anything with the “www.” prefix in the DNS Endpoint reference. However, looking at the GoDaddy certificate’s SAN, it is listing two (2) SAN values – one of them with the “www.” prefix in front of it.
I’m not an SSL cert guru… but I am suspecting that Epicor is “choosing” the SAN with the prefix in front of it as a matter of “default interpretation”.
I do not know how to get Epicor to choose/select/use the other SAN value, presuming there is a way to do it. I acknowledge that this may be an IIS issue that needs to be resolved through some configuration setting in the “web.config”(perhaps), but I don’t have that level of understanding here.
As a follow-up… I am presuming that your Epicor configuration with a GoDaddy-issued certificate wasn’t throwing DNS Identity errors whereby you were then forced to place a “www.” in the following areas:
Application Server Configuration - “DNS Endpoint Identity” field
Application Server Properties - “DNS Identity” field
Client-side “Server.config” file - “AppServerURL” value
… correct?
Does your GoDaddy certificate contain more than one Subject Alternative Name (SAN) value? If so, does either one of them have a “www.” in front of the SAN?
So, I did look into mine and it looks like my GoDaddy cert did not come with that alternate DNS, so it’s possible that that’s the root of the issue with your specific cert.
I have my Ops team generate the certs for me, so I’m not sure what’s involved, but is is possible to generate a new one that does not include the alternate?
Additionally, I’m configured a bit different than yours. I see you’re still using net.tcp–is there a reason for that? I’m pretty sure that’s being depreciated in favor of HTTPS. You might try giving the HTTPS binding a go.
Thanks for providing the details of your specific configuration with the GoDaddy-issued cert. That helps me compare - and I agree… I believe the certificate containing two SAN values might be the issue, so we’ll likely see if we can get a different cert issued by them having only one SAN.
Certainly taking nothing away from @Olga’s suggestion - as she has previously made that suggestion in the other thread I created concerning this topic (which works, by the way). I was merely looking for further understanding related to why EAC was chirping about the DNS Endpoint Identity values, which I believe are causing additional problems for us in client-server interaction.
It was one of those situations where we change one DNS Identity value… oh, but look, more errors - and you need to change this other DNS Identity value… and, oh, but look, the client doesn’t work now, so you have to change this other value, etc.
Also - thank you for mentioning the possible issue with “Net.TCP”. I wasn’t even aware that it is being phased out - so, I’ll definitely look into the HTTPS configuration instead.
I gotcha. Unfortunately, I don’t have enough understanding of what it’s doing to be able to give you a clear answer there. As far as the IIS/SSL/Epicor interaction, I’m more in the camp of “I know how to tweak it until it works” vs “I know WHY I’m tweaking each thing”, lol…
Looks like we may have to push back on GoDaddy to see if they can issue a new certificate that either [1] “flips” the two SAN values so that the one we’re trying to key on shows up last in the SAN list, [2] doesn’t contain the “www.” SAN value at all, or [3] is a “wildcard” certificate.
… which I’m testing right now, actually, with good results.
I managed to get the “HttpsBinaryUsernameChannel” to work. EAC is connecting to the server application now - no chirping about DNS Identity value mismatches (because there is no DNS Identity setting to configure).
