Changing HTTPS Certificate with API

First of all, you need to touch all elements of an objects, in case you want to update this object.

Best way is to get all the configuration running via GET, put this one into a variable and change the needed information (like certificate). Afterwards POST this value into the XG.

Thats how i would perform such a task. 

Simply get all the WAF Rules, change the value, reload the content. 

Do not use Edit, try Update. 

Thank you. 

Getting the policy first was what I need to have to see the heirarchy. Still a little confusing though. But I got it figured out.

Here is the working XML. 

Still think SOPHOS should spend a little time making the API Document a little more reader friendly.

1. curl -k my.sophis.xg:4444/.../APIController -F "reqxml=<./set_template_key.xml"
2. curl -k my.sophis.xg:4444/.../APIController -F "reqxml=</path/update_cert.xml" -F "file=@/path/cert.pem;filename=cert.pem" -F "file=@/path/privkey.key;filename=priv.key"
3. curl -k my.sophis.xg:4444/.../APIController -F "reqxml=<./set_development_key.xml"

<Request APIVersion="1702.1">
<Login>
<Username>user</Username>
<Password>pass</Password>
</Login>
<Set operation="update">
<SecurityPolicy transactionid="">
<Name>Dev Rule Name</Name>
<IPFamily>IPv4</IPFamily>
<Status>Enable</Status>
<Position>After</Position>
<PolicyType>HTTPBased</PolicyType>
<After>
<Name>Rule to place after</Name>
</After>
<HTTPBasedPolicy>
<HostedAddress>#Port2</HostedAddress>
<HTTPS>Enable</HTTPS>
<ListenPort>443</ListenPort>
<AccessPaths>
<AccessPath>
<Path></Path>
<allowed_networks>Any IPv4</allowed_networks>
<auth_profile/>
<backend>Dev webserver</backend>
</AccessPath>
</AccessPaths>
<Exceptions></Exceptions>
<ProtocolSecurity>Dev Security</ProtocolSecurity>
<CompressionSupport>Disable</CompressionSupport>
<RewriteHTML>0</RewriteHTML>
<PassHostHeader>Enable</PassHostHeader>
<Domains>
<Domain>devX.com</Domain>
...
</Domains>
<RewriteCookies>Enable</RewriteCookies>
<Certificate>Dev Cert</Certificate>
<RedirectHTTP>Enable</RedirectHTTP>
</HTTPBasedPolicy>
<IntrusionPrevention>dmzpolicy</IntrusionPrevention>
<TrafficShapingPolicy>None</TrafficShapingPolicy>
</SecurityPolicy>
</Set>
</Request>

I agree with Sire. Sophos should create proper docs on API.

I strangle sometimes to perform certain tasks through API because a better documentation could help.

Thanks for sharing your work, Sire.

NP Iferrara. 
Nothing worse then scowering the dark corners of the internet for answers, and finding that 1 guy that had the same question, but never bothered to follow up on if he found the solution or not. :)

Just to give you a Developer's perspective on this:

The API is used by less than 1% of our customers, possibly less than 0.1%.  When doing development when we add something to the UI we also add it to the API and that can take 50% of the dev/test time for how to configure the feature.  It is extraordinarily expensive compared to how often it is used.  We continue to support it, but I don't think you will see fundamental changes to it especially if that is going to make the development time even higher.

No offense, but have you looked into WHY people don't use it? 
It is a pretty powerful feature, but if a company has to assign 100 man hours to learning the syntax because the documentation is so confusing, they are obviously going to look at other ways of accomplishing what they need to. Automating certificate renewals is a pretty common need, even if you have as little as 20 certificates to manage.
Cisco has a very verbose scripting language, but they also have good documentation available. I couldn't even give a number to the amount of network admins that use scripting to manage their workload. APIs make that very convenient. 

So while I understand the need to justify the man hours to develop the documentation, you should include a CBA on how many more customers would use the API if it was easier to pick up and work with, and how many potential higher level customers would consider the XG if their Admins saw it as a robust alternative to Cisco.

It is hard to teach people API, if they are not familiar with Scripting in general.

As for now, it is XML based and it is kinda straight forward. I can actually code this without Docs. 

Because basically i "click" my object in Webadmin.

Export the configuration made in Webadmin via "Import /export" in Administration and getting the EXACT thing, i need to push to the XG. 

So you want to configure 500 Firewall rules? 

Create one Rule, export it via function, looking into the  syntax of this XML File. 

Edit the XML File, add the 499 Rules into the XML File via Script and pushing this File to the API.

Done. 

Depending how good you are with Python, Powershell, bash etc. 

I am not saying, it is good, but for people with Scripting knowledge, you can actually quite easily figure out what to do. 

But as michael said, most people are not doing it at all. They are not using scripting, who knows why. 

It is hard to teach people API, if they are not familiar with Scripting in general.

As for now, it is XML based and it is kinda straight forward. I can actually code this without Docs. 

Because basically i "click" my object in Webadmin.

Export the configuration made in Webadmin via "Import /export" in Administration and getting the EXACT thing, i need to push to the XG. 

So you want to configure 500 Firewall rules? 

Create one Rule, export it via function, looking into the  syntax of this XML File. 

Edit the XML File, add the 499 Rules into the XML File via Script and pushing this File to the API.

Done. 

Depending how good you are with Python, Powershell, bash etc. 

I am not saying, it is good, but for people with Scripting knowledge, you can actually quite easily figure out what to do. 

But as michael said, most people are not doing it at all. They are not using scripting, who knows why.