Hi all
I am having some problems getting this to work over the internet. This is using subscriptions with certificates and TLS.
I have managed to get it working over multiple machines within our internal domain, but this is the first time I have tried subscribing to an external ip address in the cloud.
These are the error’s I’m getting
On the publishing machine
[TLS!DATAPUBLISHER] Client connected to command channel.
[TLS!DATAPUBLISHER] Data publisher encountered an exception while receiving command channel data from client connection: Returned by WSARecv or WSARecvFrom to indicate the remote party has initiated a graceful shutdown sequence
[TLS!DATAPUBLISHER] Client disconnected from command channel.
On the subscribing machine
[NOJA.SG] Attempting connection to tcp://x.x.x.x:6172...
[NOJA.SG] Attempting command channel connection to publisher...
[NOJA.SG] Data subscriber encountered an exception while attempting command channel publisher connection: Unable to authenticate connection to server: Policy errors encountered during validation: RemoteCertificateNameMismatch
[NOJA.SG] Data subscriber command channel connection to publisher was terminated.
The connection string on the subscribing machine is
interface=0.0.0.0; compression=true; autoConnect=true; securityMode=TLS; server=x.x.x.x:6172; remoteCertificate=C:\Program Files\SIEGate\certs\remotes\Noja-180.SG.cer; validPolicyErrors=RemoteCertificateChainErrors; validChainFlags=UntrustedRoot; checkCertificateRevocation=False
and the Authorise subscribers looks like this on the publishing machine
Any idea’s whats going on? I have disabled the firewall on both ends to eliminate this possibility.
Hi Jeff,
RemoteCertificateNameMismatch indicates that either the Issuer’s Common Name or the Subject Alternative Name in the certificate provided by the server do not match the hostname or IP address that was used to connect to the server. This is normal when moving the connection to the internet as the certificate which is automatically generated by SIEGate only enumerates local IP addresses and hostnames for the system as it has no way of determining whether any endpoints exist to reach the system over the internet. You can solve this problem one of two ways.
- Generate a new certificate with the appropriate hostname or static IP address that will be used over the internet. The certificate along with its private key must be placed in the LocalMachine certificate store with the appropriate private key permissions on the SIEGate system. The
*.cer file needs to be generated and placed on a folder path that makes it accessible by the SIEGate service. Finally, the publisher configuration needs to be updated to reference the *.cer file. This is a fairly complex procedure, but is the more secure approach.
- Ignore the RemoteCertificateNameMismatch error by adding it to the comma-separated list of valid policy errors. This is much easier, however it’s less secure. It’s like making a declaration that you are aware of the errors in the certificate and the risk associated with connecting to this endpoint anyway.
Personally, I would recommend ignoring the error at first to get the connection established and data flowing. Then you can try following the procedure to generate a valid certificate and restore connectivity once you are sure there are no other issues with the connection.
Thanks,
Stephen
Hi Stephen
I went with option 2 and it worked first time after doing a Initialize. Thank you!
Can you recommend a tool I can use to generate a new certificate for SIEGate as you described in option 1?
SIEGate uses makecert to generate the default certificate, though it’s been criticized for the way it generates its keys. At this point, probably the most secure and accessible method for generating a self-signed certificate for SIEGate is to use PowerShell.
https://docs.microsoft.com/en-us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps
The first example on that page is probably sufficient for SIEGate, with a slight adjustment to extend the expiration.
PS C:\> New-SelfSignedCertificate -DnsName "SIEGate", "www.jeffhill.com" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter "2099-01-01"
To get rid of the RemoteCertificateNameMismatch, the important part here is the DnsName field. If you don’t have a DNS name for your public endpoint, you should be able to use an IP address instead.
Thanks Stephen. Most helpful.
