AnsweredAssumed Answered

Will a local CA work on my .local domain for Portal?

Question asked by huffmanp on Apr 4, 2018
Latest reply on Apr 5, 2018 by huffmanp

Like • Show 0 Likes0
Comment • 4

I am trying to get Portal 10.3.1 installed and work with my instance of ArcServer 10.3.1

I am working on a domain on a strictly internal LAN created by our SA and named with a .local suffix. I am just now learning about how .local domains are problematic now. http://www.mirazon.com/so-you-have-a-local-domain-now-what/ My SA launched a local Certificate authority for me, created a certificate named server.dommainname.local, and I thought I got it working on the local IIS and bound it to port 443. However, client connections from browsers still report security problems. The cert is not recognized.

ESRI tech support ran through the set up with me with screen share, then elevated me to next tier tech support, and they finally blamed the cert my SA generated.

I talked to GoDaddy about buying a cert from them, but they told me their certs will not work on a .local domain. They said domains like this are not longer “fully functional domain names”, starting in Nov. 2015. But will this also not work if we generate a domain cert from our local authority? Is this because the local domain is named *.local?

No one else has this question

Outcomes

rastrauch

Apr 4, 2018 6:04 PM

Shooting from the hip here, since I did not create our self-signed cert, and we are working with ArcGIS Server, non-federated....however, we were having issues with our proxy and secured services on our strictly in-house machine. Came down to the self signed cert. My IT guy said something about it not liking the .domain.local part of the cert.

Out IIS is setup to be https://gisdev105 without needing the .domain.local when we can the web pages. The original cert I think included the .domain.local From what I understand, he creted a new self-signed cert to match the gisdev105 portion only. So our proxy now works with our secure/non-secure services (just not totally with our custom print service...but that is another thread).

Actions

ryan.martin_APHA Apr 5, 2018 3:05 AM

Paul,

As of November 1st 2015 you can't get a publicly trusted certificate issued from a major Certifying Authority (CA) like GoDaddy for an internal/intranet web address (i.e. localhost, something.local, etc.). It seems there are a number of alternatives but I would seek expert advice on them. However, my take on it is you can do the following (for Windows Systems..I'm not sure how it differs on other operating systems)

IIS issue Self-Signed certificate and accept user warnings for each client accessing the website, manually add it to the trusted certificate store as necessary
IIS Self-Signed certificate and trust that certificate via Group Policy for all clients in the intranet domain
Setup own CA, trust that CA inside the intranet domain via Group Policy and sign own IIS Certificate Signing Requests (CSR)
Use solution like GlobalSign IntranetSSL where it will sign your CSRs for you but it still requires you to trust that CA via your Group Policy for the intranet domain.

Regarding your issues:

Have the machines that these client browsers are on been programmed (through Group Policy or otherwise) to trust certificates issued by the internal Certifying Authority you are using? I.e. is your internal CA or the specific certificate you've created listed in the "Trusted Root Certification Authorities" for that machine and other machines in the Windows Domain?

You can usually easily access this info in Chrome Settings, Advanced, Privacy and Security, Manage Certificates and then look at Trusted Root Certification Authorities.

I suspect that the error will only occur if your certificate has not been trusted but it could also have been improperly configured.

Thanks

Ryan

EDIT - Some Resources for you:

Guide on distributing certificates to client computers by using Group Policy

Guide on setting up your own CA server as a trusted CA so that any Certificates it issues should be automatically trusted by using Group Policy

Guide on trusting a self-signed certificate through Group Policy

1 person found this helpful

Actions

huffmanp @ ryan.martin_APHA on Apr 5, 2018 10:30 AM

I have read up on self-signed certs, and can't figure out what they are good for. ESRI docs on Portal https://enterprise.arcgis.com/en/web-adaptor/10.3/install/iis/enable-https-on-your-web-server-portal-.htm say that with a self-signed cert I will not be able to get Portal federated with Server, or get GISPro to use my local Portal. At one of my two locations where I'm trying to install Portal, I don't even have a local domain. Without a local domain, I can't get a self generated domain cert, but Portal is working real well for my customers when I just give them the url with port 7443 added, and tell them to add an exception to their browsers. So that's why I'd like to concentrate on getting the domain cert from our local CA working.

I think those links will be helpful.

Actions

randall_williams-esristaff

Apr 5, 2018 6:18 AM

Because your internal CA is not a 'well known' CA, it's not in your certificate store on your client machines. Like Ryan mentions above, you need to import your cert into the store for it to be trusted.

1 person found this helpful

Actions

4 Replies

rastrauch Apr 4, 2018 6:04 PM
Mark Correct
Correct Answer
Shooting from the hip here, since I did not create our self-signed cert, and we are working with ArcGIS Server, non-federated....however, we were having issues with our proxy and secured services on our strictly in-house machine. Came down to the self signed cert. My IT guy said something about it not liking the .domain.local part of the cert.

Out IIS is setup to be https://gisdev105 without needing the .domain.local when we can the web pages. The original cert I think included the .domain.local From what I understand, he creted a new self-signed cert to match the gisdev105 portion only. So our proxy now works with our secure/non-secure services (just not totally with our custom print service...but that is another thread).
Like • Show 0 Likes0
Actions
ryan.martin_APHA Apr 5, 2018 3:05 AM
Mark Correct
Correct Answer
Paul,

As of November 1st 2015 you can't get a publicly trusted certificate issued from a major Certifying Authority (CA) like GoDaddy for an internal/intranet web address (i.e. localhost, something.local, etc.). It seems there are a number of alternatives but I would seek expert advice on them. However, my take on it is you can do the following (for Windows Systems..I'm not sure how it differs on other operating systems)
1. IIS issue Self-Signed certificate and accept user warnings for each client accessing the website, manually add it to the trusted certificate store as necessary
2. IIS Self-Signed certificate and trust that certificate via Group Policy for all clients in the intranet domain
3. Setup own CA, trust that CA inside the intranet domain via Group Policy and sign own IIS Certificate Signing Requests (CSR)
4. Use solution like GlobalSign IntranetSSL where it will sign your CSRs for you but it still requires you to trust that CA via your Group Policy for the intranet domain.
Regarding your issues:

Have the machines that these client browsers are on been programmed (through Group Policy or otherwise) to trust certificates issued by the internal Certifying Authority you are using? I.e. is your internal CA or the specific certificate you've created listed in the "Trusted Root Certification Authorities" for that machine and other machines in the Windows Domain?

You can usually easily access this info in Chrome Settings, Advanced, Privacy and Security, Manage Certificates and then look at Trusted Root Certification Authorities.

I suspect that the error will only occur if your certificate has not been trusted but it could also have been improperly configured.

Thanks

Ryan

EDIT - Some Resources for you:

Guide on distributing certificates to client computers by using Group Policy
Guide on setting up your own CA server as a trusted CA so that any Certificates it issues should be automatically trusted by using Group Policy
Guide on trusting a self-signed certificate through Group Policy
1 person found this helpful
Like • Show 0 Likes0
Actions
- huffmanp @ ryan.martin_APHA on Apr 5, 2018 10:30 AM
  Mark Correct
  Correct Answer
  I have read up on self-signed certs, and can't figure out what they are good for. ESRI docs on Portal https://enterprise.arcgis.com/en/web-adaptor/10.3/install/iis/enable-https-on-your-web-server-portal-.htm say that with a self-signed cert I will not be able to get Portal federated with Server, or get GISPro to use my local Portal. At one of my two locations where I'm trying to install Portal, I don't even have a local domain. Without a local domain, I can't get a self generated domain cert, but Portal is working real well for my customers when I just give them the url with port 7443 added, and tell them to add an exception to their browsers. So that's why I'd like to concentrate on getting the domain cert from our local CA working.
  
  I think those links will be helpful.
  Like • Show 0 Likes0
  Actions
randall_williams-esristaff Apr 5, 2018 6:18 AM
Mark Correct
Correct Answer
Because your internal CA is not a 'well known' CA, it's not in your certificate store on your client machines. Like Ryan mentions above, you need to import your cert into the store for it to be trusted.
1 person found this helpful
Like • Show 0 Likes0
Actions

GeoNet

The Esri Community

Will a local CA work on my .local domain for Portal?

Outcomes

Related Content

Recommended Content