Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Can't remove vsys specific SSL TLS Service Profile

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Can't remove vsys specific SSL TLS Service Profile

L3 Networker

This is a strange issue.

 

PA-3020 recently upgraded to 7.0.4.  The firewall is in single vsys mode.

 

I installed new SSL certificates for Global Protect.  Somewhere during the process of installing the new certificate and upgrading to 7.0.4, an ssl-tls service profile was automatically created.  I didn't create it.  I'm trying to delete that certificate but it won't let me as long as the ssl tls service profile exists.

 

Here's the weird part.  In the GUI, the profile does not show up under Devices > Certificates > SSL TLS service profiles but is available when choosing the SSL TLS service profile under the Global Protect Portal configuration.  When I create a new SSL TLS service profile, it does show and it is shown as 'shared'.

 

When I go to the CLI and do a 'show config' (not in configure mode), The XML output shows the hidden profile located at:

</config>

<devices>
    <entry name="localhost.localdomain">

      <vsys>
        <entry name="vsys1">

            <ssl-tls-service-profile>

            <entry name="GP_GD_Chained_2019-ssl-tls-service-profile">
              <certificate>GP_GD_Chained_2019</certificate>
              <protocol-settings/>
            </entry>
          </ssl-tls-service-profile>
        </entry>
      </vsys>
    </entry>
  </devices>
</config>

 

But, when I enter configure mode, I cannot locate this ssl tls service profile.  I've exported the config as set commands and done a search.  It doesn't show it.  I can't change the vsys I'm viewing because I'm not in multi-vsys mode.

 

The ssl tls service profile I created manually, shows up under <shared> in the CLI and I can view it from configure mode.

 

I'm trying to avoid enabling multi-vsys support.  I just don't want to have to create a bunch of local accounts and authentication profiles that exist both as shared and in vsys1.

 

Anyone have an idea how I can remove this profile?

 

Thanks.

1 accepted solution

Accepted Solutions

I was able to reproduce the exact same issue.

 

If you are not a non vsys firewall and on a previous version with GP Config, as soon as you move to 7.0.X, it creates a corresponding SSL/TLS profile under vsys config. Now this cannot be accesses via GUI or CLI.

 

Here is what you can do to get rid of it.

 

1. Create a similar SSL/TLS profile under shared hierarchy but with a different name. Bind the same certificate as the previous one.

 

2. Change the SSL/TLS profile binded to the Portal and Gateway configs to this new one.

 

3. Delete the SSL/TLS profile using either of below methods:

    a) Export and delete config

        i. Export this candidate config using config snapshot to your PC.

        ii. Go to the SSL/TLS profile under shared hierarchy and delete the profile. Save the file

        iii. Reimport this config into firewall and load the config, and then commit

 

    b) Using XML APIs

        i. Generate XML API Key using a broswer tab: https://<hostname>/api/?type=keygen&user=<username>&password=<password>

        ii. Note the keyvalue. Use this in the next step

        ii. Copy the following URL in the browser: https://<hostname>/api/?type=config&action=delete&key=<keyvalue>&xpath=/config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/ssl-tls-service-profile/entry[@name='GP_GD_Chained_2019-ssl-tls-service-profile']

 

 

View solution in original post

13 REPLIES 13

L5 Sessionator

Whe you go to device>certificate management>"ssl/tls profile" are you changing the location?

 

SSL-TLS.png

L4 Transporter

Hi,

 

Could you enumerate the exact steps followed. Did you generate certificate/ setup GP before upgrade or was all this done after upgrade. 

 

I will have to test this as SSL/TLS profile is a mandatory field on Portal Configuration, and I am wondering if firewall might have created an automatic binding.

 

BR

 

To the post about setting location:

Location is not a choice since I have not enabled multi-vsys support.  I'm in single vsys.

 

As for the order I did it, I *think* I upgraded to 7.0.4 before installing the certificate.  Sadly, I don't remember.

 

I can tell you that the binding was created automatically because I didn't create it.

Try this.

 

Create a ssl-tls with same name that is shown under the global protect gateway "GP_GD_Chained_2019-ssl-tls-service-profile" do a commit and then delete.

Tried it.

 

It created the new ssl tls service profile as a shared object.  No effect on the one that exists as a vsys1 specific.

 

I really hope I don't have to enable multi-vsys to fix this.  It's one of those things that once it's done, you just don't want to undo it.

 

PA SSL TLS Profile.gif

 

Try this take config backup. Then enable multivsys do not do any commit as commit is not done so it will not affect anything do as I have mentioned in previous comment and then turn off multivsys.

Stupid question.

 

Once I enable multi-vsys, remove the profile then disable multi-vsys, I then commit.  So the idea is that the system will never see the multi-vsys configuration but I'd still be able to remove the profile.

 

Also, I remember the order I did things.

 

The certificate was installed before I upgraded.  The client's cert was expiring so they wanted that done first.  Then I proceeded to upgrade the box.  The certificate was installed under PAN-OS 5.0.6.  Yes, the box hasn't been updated since it was installed.  So, once the cert was installed I went through the process of upgrading from 5.0.6 all the way to 7.0.4.

 

Fun and games.

I just tried it.  The issue is that as soon as you try to enable multi-vsys, it wants to commit.  It won't let me move forward without commiting.  It was a good idea.

I was trying to figure out just exactly what the affects are when you enable then disable multi-vsys support.

 

I downloaded the VSYS tech note and went through it but it doesn't really deep dive into how it affects the configuration.

 

Any idea what the affects would be if I enable multi-vsys to remove that certificate & then disable it right after.

Whatever changes that you will do will be reverted back once you disable multivsys. Atlease you will have a config back before changes you can revert back.

 

Or else try to export the config file and try to delete it from the file then upload it. This I have tried with two firewall and it worked.

I was able to reproduce the exact same issue.

 

If you are not a non vsys firewall and on a previous version with GP Config, as soon as you move to 7.0.X, it creates a corresponding SSL/TLS profile under vsys config. Now this cannot be accesses via GUI or CLI.

 

Here is what you can do to get rid of it.

 

1. Create a similar SSL/TLS profile under shared hierarchy but with a different name. Bind the same certificate as the previous one.

 

2. Change the SSL/TLS profile binded to the Portal and Gateway configs to this new one.

 

3. Delete the SSL/TLS profile using either of below methods:

    a) Export and delete config

        i. Export this candidate config using config snapshot to your PC.

        ii. Go to the SSL/TLS profile under shared hierarchy and delete the profile. Save the file

        iii. Reimport this config into firewall and load the config, and then commit

 

    b) Using XML APIs

        i. Generate XML API Key using a broswer tab: https://<hostname>/api/?type=keygen&user=<username>&password=<password>

        ii. Note the keyvalue. Use this in the next step

        ii. Copy the following URL in the browser: https://<hostname>/api/?type=config&action=delete&key=<keyvalue>&xpath=/config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/ssl-tls-service-profile/entry[@name='GP_GD_Chained_2019-ssl-tls-service-profile']

 

 

You nailed it.  Exporting the config, editing it and reimporting it worked like a charm.

 

I should've thought of that.  I've done it enough times during migrations.

 

I can't thank you enough for all the help and the work you've put into this.

Glad to know that It worked.

I have also mentioned the same in the comment that I have posted on 27-01-2016 10:57 PM.

  • 1 accepted solution
  • 17249 Views
  • 13 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!