Rest calls from PowerShell failing

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Rest calls from PowerShell failing

L1 Bithead

I have a script that I use that reads a copy of my palo's configuration that I manually export. I am looking to create a PowerShell script that can call the rest service instead of having to manually export the XML configuration file. I also want to be able to give the script to co-workers (using their own key). However, when I go to call the service I either the error that the connection was closed or an HTTP error.

 

I tested the URI that I am using in small python script and received a 200 status code. I do not know Python well enough to be able to write the script in it and Python is widely installed in my office.

 

I have been fighting this for a while I am at my wits end as I cannot figure out what it is that I am doing wrong.

 

Here is my code:

 

$rKey = "<KEY>"
$Headers = "$rKey application"
$type = "config"
$xpath = "/config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/address"
$strUri ="https://<URL>/api/?type=config&action=get&key=$dKey&xpath=$xpath"


#Tried this after the first failed. Same results.
Invoke-WebRequest -Method Get -Uri "https://<URL>/api/?type=config&action=get&key=$rKey&xpath=/config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/address"

#started with this, had error message.
Invoke-WebRequest -Method Get -Uri $strUri

I am new to using rest and this is my first attempt at something other than using a cmdlet to get my external IP.

 

Any help would be greatly appreciated.

 

Thanks,
Sean

1 accepted solution

Accepted Solutions

It appears the issue is with PS not liking the certificate we used for the management interface. I added the following two lines which resolved the issue:

 

 
$AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
 
The top of my script looks like this:
 
 
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]::SecurityProtocol = $AllProtocols
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
 
Hopefully this will help someone else.

View solution in original post

7 REPLIES 7

L4 Transporter

Can you share the error? The Invoke-WebRequest looks correct. You can also try your API call in the browser and the error information returned may be a little more verbose.

I get the following error message when I use a variable that builds the URI:

 

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At C:\Users\meowz\Documents\Scripts\powershell\palo-search-ps\palo-rest.ps1:20 char:1
+ Invoke-WebRequest -Method Get -Uri $strUri
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

 

When I use the URI directly in the call (invoke-webrequest -method...) i get the following error:

 

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At C:\Users\meowz\Documents\Scripts\powershell\palo-search-ps\palo-rest.ps1:20 char:1
+ Invoke-WebRequest -Method Get -Uri "https://<URL TO PALO>/ap ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

 

When I copy the URI and use it in the browser I get the list of addresses returned.

If I attempt to use Invoke-ResetMethod I get the same errors.

 

It would be helpful to see the request/response in that case. Could you get the URI's from a packet capture potentially, sanitize the IP and keys, and paste them over?

I will try, never had to sanatize a packet capture before.

It appears the issue is with PS not liking the certificate we used for the management interface. I added the following two lines which resolved the issue:

 

 
$AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
 
The top of my script looks like this:
 
 
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]::SecurityProtocol = $AllProtocols
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
 
Hopefully this will help someone else.

Good stuff! Thanx! 

This.

 

Powershell does not like the TLS versions used by default on the firewall - also in your "intro" block, I see disabling certificate checking, which is another common error that someone may be able to fix if google leads them to your post.

 

I have a "default" i build all my PS scripts from that includes this block and a few calls to obtain the API key because of this.

 

Note, sometimes these commands require elevation in PS or a change in executionpolicy, but I have not seen this recently, so an update may have changed that behavior.

  • 1 accepted solution
  • 11194 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!