Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 1516 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Update Certificates via API: Did I get it right?

dtconnect

In 2018, Sophos integrated Let's Encrypt with their UTM series, leaving XG(S) users anticipating a similar feature. Many, including us, have turned to API solutions due to the lack of progress which is fine. However, the XG API feels less refined compared to SG's REST API, in my view, possibly due to the minimalistic API documentation and the absence of an API browser.

Our objective is straightforward: to generate/update multiple Let's Encrypt certificates and seamlessly integrate them into our firewall configurations without altering the existing setup/order of WAF rules.

Here's the elaborate journey we undertake for what should be a simple automation task:

1. CERTBOT: Generate a new certificate: cert.pem, key.pem.
2. API: Upload the new certificate with a temporary name ('cert_temp') to circumvent direct replacement issues due to rule bindings.
3. API: Fetch a list of all firewall rules (WAF) utilizing the 'cert' certificate.
4. API: Retrieve a list of all firewall rule groups containing a rule that uses the old 'cert'. (Because a rule inside a group will loose its group information after an update)
5. API: Update individual firewall rules to replace the 'cert' with the temporary 'cert_temp', requiring a complete rule update. (Why can't I just pass the new certificate?)
6. API: Refresh firewall groups entirely due to the inability to specify groups during rule updates, which inadvertently removes rules from their groups. Besides, this step is also necessary to maintain the order of the rules, which is otherwise lost if the rule is(was) part of a group.
7. API: Upload the new certificate as 'cert'.
8. API: Update (overwrite) the old 'cert' with the new certificate.
9. API: Gather all firewall rules (WAF) that now use 'cert_temp'.
10. API: List all firewall rule groups where a rule employs 'cert_temp'.
11. API: Modify each rule to swap 'cert_temp' with the new 'cert'.
12. API: Fully update firewall groups again (refer to step 6).
13. API: Delete the temporary certificate.
14. Cross Fingers: Hope for the best!

Are we complicating the process unnecessarily? Could any steps be combined or eliminated to streamline the task? To conclude, it's worth noting that our process feels very unstable, especially when the certificate is used in more places than just the firewall rules (currently, our automation does not handle this). In such cases, we find ourselves having to modify and change large parts of the configuration, which introduces the potential for errors. This complexity underscores the need for a more streamlined and reliable approach to certificate management in such critical infrastructure - or at least a clarification for us if we are overcomplicating things :)

Personally, I think that the API should take care of all the steps so that I just have to do Step 7+8. I just feels wrong the way we are doing it now...



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to LuCar Toni
    Thank you for your input! It is very interesting.

    Although this doesn't directly answer my question. The question is: are we executing the right steps, or could the process be streamlined in terms of the number and type of API requests without resorting to a different tool? Our script is operational and deployed in production, yet it seems somewhat fragile. However, it would be helpful if you could demonstrate what the pipeline is actually performing, specifically concerning XML Requests. This insight could allow me to review the steps and potentially refine our script.

    To clarify: I'm not inherently opposed to using Sophos Factory and will definitely consider it in the future, but there are several reasons we prefer not to employ it for this project:

    1. I'm hesitant to store my firewall admin credentials in the cloud:

      • Perhaps it's a bit traditional, but it doesn't sit well with me. Although I'm aware the credentials are likely encrypted, I believe it's done symmetrically.

    2. I prefer not to expose my Management Interface to the WAN:

      • Even if it's protected by a rule that only permits connections from certain AWS IP addresses.

    3. We already implement extensive network automation within our local network and framework:

      • Using Factory for the sole purpose of integrating with Sophos XGS doesn't seem justified. It's unnecessary to adopt another framework for just one component, and employing Factory doesn't improve the XGS API.
  • 0 in reply to dtconnect

    Generally speaking, your approach should be fine. Before Factory, i did the same with some firewalls, just - As said - With the LE + Date name and replace this one everywhere. 

    __________________________________________________________________________________________________________________

Unfiltered HTML