You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the paloaltonetworks.panos.panos_op module to create a CSR request with XML API commands, it does not show as pending in the GUI and places the CSR in vsys instead of shared config
Expected behavior
After getting "Successfully generated certificate and key pair" from the XML API command, I should be able to see the pending CSR request in the GUI, and in the shared config (not vsys), because it should be a 1:1 match with creating a CSR in the GUI.
Current behavior
The API responds with success but does not replicate the manual steps, does not reflect pending status in the GUI, and places the CSR in vsys in the running-config. If you generate the CSR with the GUI, it will show a pending status on the devices/certificates page and it will place the pending CSR in config/shared.
The command works on execution, but not on implementation:
Show the pending status of the CSR in the GUI and place the CSR in the same place in the config as if you were using the GUI.
Steps to reproduce
Refer to Current Behavior section. Please take my word for it when I say I have spent hundreds of hours on this issue and have an active TAC case open that 4 engineers have been on unable to resolve.
I tried circumventing this by requesting CSR generation using the xpath option, that does not work and tells me I can't override it, I've also tried using the set command and it tells me to try overriding it, so it places me in an endless error loop:
I have also attempted using the configure option, to no avail.
- name: Generate CSR on Palo Alto Device
paloaltonetworks.panos.panos_op:
provider: "{{ device }}"
cmd: |
configure
service certificate
set certificate name {{ cert_filename }}
set certificate common-name {{ cert_name }}
set certificate signed-by External Authority (CSR)
set certificate algorithm RSA
set certificate rsa key-size 2048
set certificate country US
set certificate state New York
set certificate locality Brooklyn
set certificate organization blah
set certificate organization-unit blah blah
set certificate shared
generate certificate
show certificate
register: csr_output
Evidence of CSR going to vsys:
Context
I am trying to automate end-to-end certificate installations signed by third party for the Palo firewalls. I have successfully generated it end-to-end, but I can never get the blue-checkmark key to show up on the Palo device in the GUI because I believe it is related to how the Palo Alto generates the CSR on the device. I do not want the key to be generated by open-ssl or some other device because of strict cybersecurity reasons of the key never leaving the device. That is why I need this to work properly, so I believe the CSR generation contains a bug, at least with this ansible module.
The workaround to get the XML API CSR to go into the shared config is to utilize the ansible.builtin.uri module and completely circumvent this collection:
- name: Generate CSR on Palo device
vars:
org: "Company With Spaces"
oum: "Team With Spaces"
ansible.builtin.uri:
url: https://{{ firewall }}/api/?type=op&cmd=<request><certificate><generate><ca>no</ca><name>{{ cert_name }}</name><certificate-name>{{ cert_filename }}</certificate-name><organization>{{ org | urlencode }}</organization><organization-unit><member>{{ oum | urlencode }}</member></organization-unit><email>[email protected]</email><country-code>US</country-code><state>Florida</state><locality>Tampa</locality><algorithm><RSA><rsa-nbits>2048</rsa-nbits></RSA></algorithm><signed-by>external</signed-by></generate></certificate></request>&key={{ panorama_api_key }}
validate_certs: no
register: csr_output
Thankfully after a 4 week case a TAC engineer was able to help me, but this is still a bug in paloaltonetworks.panos.panos_op
Describe the bug
When using the paloaltonetworks.panos.panos_op module to create a CSR request with XML API commands, it does not show as pending in the GUI and places the CSR in vsys instead of shared config
Expected behavior
After getting "Successfully generated certificate and key pair" from the XML API command, I should be able to see the pending CSR request in the GUI, and in the shared config (not vsys), because it should be a 1:1 match with creating a CSR in the GUI.
Current behavior
The API responds with success but does not replicate the manual steps, does not reflect pending status in the GUI, and places the CSR in vsys in the running-config. If you generate the CSR with the GUI, it will show a pending status on the devices/certificates page and it will place the pending CSR in config/shared.
The command works on execution, but not on implementation:
Possible solution
Show the pending status of the CSR in the GUI and place the CSR in the same place in the config as if you were using the GUI.
Steps to reproduce
Refer to Current Behavior section. Please take my word for it when I say I have spent hundreds of hours on this issue and have an active TAC case open that 4 engineers have been on unable to resolve.
Evidence of CSR going to vsys:
Context
I am trying to automate end-to-end certificate installations signed by third party for the Palo firewalls. I have successfully generated it end-to-end, but I can never get the blue-checkmark key to show up on the Palo device in the GUI because I believe it is related to how the Palo Alto generates the CSR on the device. I do not want the key to be generated by open-ssl or some other device because of strict cybersecurity reasons of the key never leaving the device. That is why I need this to work properly, so I believe the CSR generation contains a bug, at least with this ansible module.
I noticed in https://github.com/PaloAltoNetworks/pan-os-ansible/blob/develop/plugins/modules/panos_op.py that you are basically defaulting all commands to go into vsys, at least from my feeble understanding of Python. There should be an option to choose to write to the 'config/shared', not 'vsys'. Not every environment has vsys configured.
Your Environment
The text was updated successfully, but these errors were encountered: