Remote server cannot access API

[Guest Remy]

We are trying to use the Anonymous API in combination with Powershell for our purposes.

 

$GetURL = 'https://passwordstateserver:port/api/passwords/$ID'
$pwd1 = (Invoke-RestMethod -Method GET -Uri $GetURL -Headers @{ "APIKey" = $ApiKey }).PasswordId
Write-Host "$ID Result is $pwd1"

 

When we try to use it on a server A - in domain A1 - to connect to the Passwordstate server B - in domain B1 - it doesn't work.

I tested it first on my local machine - domain A1 - which works. So that was promising.

 

We use a powershell session for it on server A, so that we can connect with server B. And there we execute the Powershell code to retrieve a password. But even if we don't use the session, we still get the same error.

The session works, btw, which I checked by executing below code in Powershell. So that should be good.

$test = Invoke-Command -Session $sessionModules -ScriptBlock { Get-ChildItem "C:\Temp" }
Write-Host "Test: $test"

 

If we use below code to test whether we get anything as a return value

Invoke-RestMethod -Method GET -Uri 'https://www.google.com'
Invoke-RestMethod -Method GET -Uri 'https://passwordstateserver:port/api'

we see that we get a response from google. The response we get from the passwordstateserver is 

Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send.
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

If we execute 

 

$GetURL = 'https://passwordstateserver:port/api/passwords/$ID'
$pwd1 = (Invoke-RestMethod -Method GET -Uri $GetURL -Headers @{ "APIKey" = $ApiKey }).PasswordId
Write-Host "$ID Result is $pwd1"

we still get the 'underlying connection was closed' error.

 

This seems like there's an issue with accessing the API.

I added a different website to the server, which gives us a return value as well, so it's not the server itself that doesn't allow us to make a connection.

 

Our server is a Windows 2012R2 Server and we use a self-signed certificate. I know there is an issue with Powershell concerning TLS1.2, but on our server we have (according to the IISCrypto as well) TLS 1.0, 1.1 and 1.2 available. The fact it works on my local machine confirms that it does not seem to be an issue.

 

We also checked the API IP range setting, which has no limitations for testing purposes for now (we have a test passwordlist for this purpose, so not global).

 

Do you have any idea what can be the cause?

 

 

[support]

Hello Remy,

 

Can you try adding the following to the top of your script - this will allow for self-signed certificates, and TLS restrictions.

 

# Ignore certificate error if using a non trusted certificate
add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
$AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols

 

Regards

Click Studios

[Remy]

Okay, this was odd. I had to register with a different build (8315) than the one we used (8205), as it was rejected as invalid.

Anyway, thanks for your response, although unfortunately that's not helping as we already had that in place.

 

Correction

I noticed I made a mistake in my original post, so I'm going to correct that first to avoid misconceptions. 

The passwordstate is on Server A in Domain A1. My local workstation is in Domain A1 as well. That works.

The server that needs to use the API is located in Domain B1. 

 

Solution

We had a bunch of issues which obscured our actual problems, but we solved it nonetheless. I thought I'd share it here for people who might encounter the same problem.

 

First of all, the issue turned out to be the fact I used the IP-address rather than the hostname upon calling the Invoke-RestMethod. 

$GetURL = 'https://passwordstateserver:port/api/passwords/$ID'
$GetURL = 'https://192.168.1.13:80/api/passwords/$ID'

Which was logical by that time as the hostname wasn't registered in the DNS, as it was not a server included in the domain. After I switched that out (it wasn't necessary after all, since we make a session to the actual passwordstate server anyway), we got rid of below error.

Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send.
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

 

Apparently after the untimely reboot of the server last week, the TrustedHost also happened to be missing the server we wanted to have there. Note that the IP-address is not the actual ip-address.

New-PSSession : [192.168.1.13] Connecting to remote server 192.168.1.13 failed with the following error message : The WinRM client cannot process the request.

We fixed that by executing PowerShell with below code. 

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "MachineA, 192.168.1.13" 

For fun, I removed the code for the protocols and get the following error:

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

That one's actually a whole lot clearer on what the issue is and it would be easier to figure out it's the self-signed certificate being the culprit. So it looks like we were on a goose chase by having used an ip-address rather than a hostname in the url. After that, the errors were pretty clear on what needed to happen and we could dix that.

 

So, in the end we figured it out after all, but thanks for helping us with the code that would've blocked us if we hadn't already applied it!