Unexpected Behavior a10.acos_axapi.a10_file_ssl_cert

Product Discussions ADC - Application Delivery
,
1

ACOS 6.0.4
axapi 6.0.4
Due to the on-box limitations of A10 Thunder 1040 ACME implimentation, we have a need to generate certificates elsewhere and shuttle them in.
Using the following ansible playbook part:
Expected Behavior is for the playbook to identify whether the cert exists or doesn’t on the a10 partition. If it doesn’t exist, use action: import. If it does exist, use action: replace. This does indeed do that, and imports the cert, chain, and key. When it sets to replace, the playbook completes and seemingly is ok, however the certificate, key, and chain do not get replaced. I’m wondering if anyone has run into this issue before and how you’ve gotten around it. This is true for certs, keys and chains that are not bound to an ssl template, when they are, and when they are and the ssl template is part of an slb deployment. I’ve observed no difference among those 3 scenarios.

- name: "Probe for existing certificate on {{ current_location }}"

  a10.acos_axapi.a10_file_ssl_cert:

    ansible_host: "{{ current_location }}"

    ansible_username: "{{ ansible_username }}"

    ansible_password: "{{ ansible_password }}"

    ansible_port: "{{ ansible_port }}"

    a10_partition: "{{ slb_data[0].value.partition }}"

    file: "{{ vip }}"

    state: present

  check_mode: true

  register: cert_probe

  failed_when: false




- name: "Determine A10 Action for {{ current_location }}"

  set_fact:

    a10_action: "{{ 'replace' if (cert_probe.axapi_calls | string is search(vip)) else 'import' }}"




- name: "Decision Log"

  ansible.builtin.debug:

    msg: "Targeting {{ current_location }}. Selected Action: [{{ a10_action }}]"


- name: "Deliver Cert and Chain to {{ current_location }}"

  a10.acos_axapi.a10_file_ssl_cert:

    ansible_host: "{{ current_location }}"

    ansible_username: "{{ ansible_username }}"

    ansible_password: "{{ ansible_password }}"

    ansible_port: "{{ ansible_port }}"

    a10_partition: "{{ slb_data[0].value.partition }}"

    state: present

    action: "{{ a10_action }}"

    file: "{{ item.name }}"

    file_handle: "{{ item.name }}"

    file_path: "{{ item.path }}"

    certificate_type: pem

  loop:

    - { path: "{{ cert_path }}", name: "{{ vip }}" }

    - { path: "{{ chain_path }}", name: "{{ vip }}_full_chain" }

  throttle: 1


- name: "Deliver Private Key to {{ current_location }}"

  a10.acos_axapi.a10_file_ssl_key:

    ansible_host: "{{ current_location }}u"

    ansible_username: "{{ ansible_username }}"

    ansible_password: "{{ ansible_password }}"

    ansible_port: "{{ ansible_port }}"

    a10_partition: "{{ slb_data[0].value.partition }}"

    state: present

    action: "{{ a10_action }}"

    file: "{{ vip }}"

    file_handle: "{{ vip }}"

    file_path: "{{ key_path }}"

  throttle: 1
2

Hi @njd67 ,

I’ve run into this issue before, where setting action: replace for the a10_file_ssl_cert or a10_file_ssl_key modules doesn’t appear to work, despite the playbook seemingly running fine.

One workaround I’ve found is to do the following:

  • Use action: import instead of action: replace
  • Rename the new SSL certificate, chain & key files to match the old SSL certificate, chain & key you’re trying to replace

I’ve included an example using the a10_file_ssl_cert_key module, though it should also work for a10_file_ssl_cert and a10_file_ssl_key.

- name: Import and overwrite existing SSL cert/key file using local file path
  a10.acos_axapi.a10_file_ssl_cert_key:
    # local file name
    file: "ssl-cert-key-bundle.tar.gz"
    file_handle: "ssl-cert-key-bundle.tar.gz"
    # local file path
    file_path: "/directory/containing/ssl-cert-key-bundle.tar.gz"
    action: import

This should allow you to replace the SSL files, even while they’re attached to existing templates.

3

FYI I was informed by out PS engagement SMA that this is a bug in ACOS 6.0.4 where replace or overwrite does not work.

My solution was to upload a 2nd certificate and key while capturing existing and then remove the existing. A side-by-side replacement strategy is the only thing that works.

4

Thanks for the update! Good to know about the bug in 6.0.4. There are quite a few fixes in the later 6.0.x releases, and I would suggest upgrading if that is possible for your environment. 6.0.8 is LTS and would be a good target.

5

Yes I would love to, BUT we’re planning to move onto harmony which we were informed is only compatible up to 6.0.4