Palo Alto Download Error Problem With The Local Ssl Certificate
Brandi Baylon
How exactly do I do this? The firewalls being pushed to are brand new out of the box. I have never had issues with pushing app updates or software before? Did they change something out of the box? My issue is EVERY palo we unbox has to manually be updated on the firewall itself, panorama fails to push to every single one with this same error message. "Download error: Problem with the local SSL Certificate"
We recently got a RMA replacement in for a failed PA5250 in HA but we are now noticing that Dynamic updates are not downloading and installing. We get a message in the Panorama Job Schedules section stating "Failed to upload image. Device msg:'Failed to download panup-all-antivirus-3977-4488. Download error:Problem with the local SSL certificate'
Relating to 'SSL certificate problem: unable to get local issuer certificate' error. It is important to note that this applies to the system sending the CURL request, and NOT the server receiving the request.
In my case it turned out to be a problem with the installation of my certificate on the service I was trying to consume with cURL. I failed to bundle/concatenate the intermediate and root certificates into my domain certificate. It wasn't obvious at first that this was the problem because Chrome worked it out and accepted the certificate in spite of leaving out the intermediate and root certificates.
We ran into this error recently. Turns out it was related to the root cert not being installed in the CA store directory properly. I was using a curl command where I was specifying the CA dir directly. curl --cacert /etc/test/server.pem --capath /etc/test ... This command was failing every time with curl: (60) SSL certificate problem: unable to get local issuer certificate.
Had that problem and it was not solved with newer version. /etc/certs had the root cert, the browser said everything is fine. After some testing I got from ssllabs.com the warning, that my chain was not complete (Indeed it was the chain for the old certificate and not the new one). After correcting the cert chain everything was fine, even with curl.
After attempting all of the above solutions to eliminate the "curl: (60) SSL certificate problem: unable to get local issuer certificate" error, the solution that finally worked for me on OSX 10.9 was:
I just experienced this same problem with the Laravel 4 php framework which uses the guzzlehttp/guzzle composer package. For some reason, the SSL certificate for mailgun stopped validating suddenly and I got that same "error 60" message.
I'm using Centos 7 with the free version of virtualmin. With Virtualmin you can create a wordpress website. There is functionality that will automatically update your ssl certificate for you. I noticed that /etc/httpd/conf/httpd.conf did not contain an entry for SSLCertificateChainFile. Which should be set to something like /home/websitename/ssl.combined. Updating that file accordingly and restarting apache fix this problem for me. I discovered my issue trying to install a jetpack plugin for wordpress. A search on the internet led me to realize that I didn't have SSL Configured. I followed Redhat's instructions on how to install a certificate. I hope this was useful to someone.
I have a proper solution of this problem, lets try and understand the root cause of this issue. This issue comes when remote servers ssl cannot be verified using root certificates in your system's certificate store or remote ssl is not installed along with chain certificates. If you have a linux system with root ssh access, then in this case you can try updating your certificate store with below command:
I am trying to make a self-signed cert for use with Global-Protect in my lab. I go into Device, Certificates, Generate, give the cert a name, Root_GP_Cert, common name of 192.168.189.155 which is the WAN side IP Address. Click the Certificate Authority box and click ok. Then I click on Generate again, this time I use a different name, common name is 192.168.189.155 and I select the Root_GP_Cert in the Signed By drop-down box and I give a Certificate Attribute of IP Address 192.168.189.155 but it gives me the error of: Failed to insert certificate into configuration. Only self signed CA certificates can have identical subject and issuer fields.
I have a couple of jobs which get code from a Git repository, I have the Git plugin installed on the Jenkins server ( ). When I add the Repository URL in the configuration for the job on Jenkins I get an error message which claims it can't access the URL because "status code 128: SSL certificate problem: unable to get local issuer certificate". Most advice I've seen immediately starts talking about self-signed certificates but this is a public SSL cert. The other option seems to be to turn off Git SSL verification but that doesn't sound right to me.
I have a problem with my Fedora 8 installation. It looks that wget doesn't know how to verify SSL certificates any more. It's strange because I have another Fedora 8 box which I believe has the same configuration and it works!
Do you have any idea where I can find information on the errors provided from the SSL configuration? I have tried path to certificates vs putting the cert within the SSL box. With any reference to certificates the agent will not open the port for listening.
One bit of easy guidance here is that if you can't use Negotiate authentication, you really really should be using HTTPS with verifiable certificates. However if you are just trying to get off the ground with local Vagrant boxes and you find yourself in a situation getting WinRM Authentication errors but know you are passing the correct credentials, please try running these on the remote machine before inflicting personal bodily harm.
Windows remote communication tends to be easier when you are using domain accounts. This is because domains create implicit trust boundaries so windows adds restrictions when using local accounts. Unfortunately the error messages you can sometimes get do not at all make it clear what you need to do to get past these restrictions. There are two issues with local accounts that I will mention:
One thing that has previously tripped me up and I have seen others struggle with is related to authenticating local users. You may have a local user (not a domain user) and it is getting access denied errors trying to login. However if you prefix the user name with './', then the error is resolved. The './' prefix is equivelent to '\'. Note that the './' prefix may not work in a windows login dialog box. In that case use the host name or IP address of the remote machine instead of '.'.
This does not apply to the built in administrator account. So if you only logon as administrator, you will not run into this. However lets say I create a local mwrock account and even add this account to the local Administrators security group. If I try to connect remotely with this account using the default remoting settings on the server, I will get an Access Denied error if using powershell remoting or a WinRMAuthentication error if using the winrm gem. This is typically only visible on 2012R2. By default, the winrm service is running on a newly installed 2012R2 machine with an HTTP listener but without the LocalAccountTokenFilterPolicy enabled, while 2008R2 and client SKUs have no winrm service running at all. Running winrm quickconfig or Enable-PSRemoting on any OS will enable the LocalAccountTokenFilterPolicy, which will allow local accounts to logon. This simply sets the LocalAccountTokenFilterPolicy subkey of HKLM\software\Microsoft\Windows\CurrentVersion\Policies\system to 1.
This article helps you resolve an error that occurs when you try to import a Secure Sockets Layer (SSL) private key certificate (.pfx) file into the local computer personal certificate store by using Microsoft Internet Information Services (IIS) Manager.
Some trust managers can make trust decisions without being explicitly initialized with a KeyStore object or any other parameters. For example, they may access trust material from a local directory service via LDAP, use a remote online certificate status checking server, or access default trust material from a standard local location.
The primary responsibility of the KeyManager is to select the authentication credentials that will eventually be sent to the remote host. To authenticate yourself (a local secure socket peer) to a remote peer, you must initialize an SSLContext object with one or more KeyManager objects. You must pass one KeyManager for each different authentication mechanism that will be supported. If null is passed into the SSLContext initialization, then an empty KeyManager will be created. If the internal default context is used (for example, an SSLContext created by SSLSocketFactory.getDefault() or SSLServerSocketFactory.getDefault()), then a default KeyManager is created. See Customizing the Default Keystores and Truststores, Store Types, and Store Passwords. Typically, a single key manager supports authentication based on X.509 public key certificates. Some secure socket implementations may also support authentication based on shared secret keys, Kerberos, or other mechanisms.
Cause: There was a problem with SSLContext initialization, for example, due to an incorrect password on a keystore or a corrupted keystore (a JDK vendor once shipped a keystore in an unknown format, and that caused this type of error).
If an authentication error occurs during communication between the client and the server (whether using a web server or ClassFileServer), it is most likely because the necessary keys are not in the truststore (trust key database). See Terms and Definitions. For example, the ClassFileServer uses a keystore called testkeys containing the private key for localhost as needed during the SSL handshake. The testkeys keystore is included in the same samples/sockets/server directory as the ClassFileServer source. If the client cannot find a certificate for the corresponding public key of localhost in the truststore it consults, then an authentication error will occur. Be sure to use the samplecacerts truststore (which contains the public key and certificate of the localhost), as described in the next section.
3a7c801d34