Provide REST API for certificate upload for GS1900 series switches (and more?)

coderjoe
coderjoe Posts: 13  Freshman Member
First Comment

Note: This is going to be a long and complicated description. If you would like to have a detailed discussion I am very interested. Please feel free to reach out privately.

I am trying to add support for GS1900 series switches to the opensource acme.sh project (https://github.com/acmesh-official/acme.sh) so that I can automate certificate management. My end goal is to get automatic certificate deployment working. A secondary goal once this is supported in acme.sh is to get support into the OPNSense acme.sh plugin for all GS1900 series switches.

I am making this work as a test on my own network by just simulating login to the web interface and simulating the various UI operations required to upload the file.

I am currently running into a few problems:

1. The switch login process is very complicated, since it goes through the web UI.

2. The file upload process is very complicated because it relies on browser style uploads.

3. The file upload appears to expect a verbatim binary upload of the certificate, and does not support URL encoding, which is complicating the implementation and giving the original author of the acme.sh project concerns about how I'm forced to implement.

In order to simplify this process I would like one of the following:

1. Preferred option: REST API for Certificate Upload

  • Located somewhere like /cgi-bin/restuploadcert.cgi
  • Only accessible over HTTPS
  • Accepts basic auth for user/password
  • Accepts a POST request
  • The body of the request must be a base64 encoded version of the pkcs12 certificate to upload
  • If successful it returns HTTP Status Code 200 (OK) with no body
  • If it failed with invalid user or password return HTTP Status code 403 (Forbidden) with no body
  • If it fails due to an invalid certificate return HTTP status code 400 (Bad Request) with the body of the response containing the reason for the failure

2. Alternative option: Update existing httpupload.cgi to support base64 encoding

  • Update the existing upload script at /cgi-bin/httpuploadcert.cgi
  • add an additional form element which allows you to specify if the file is base64 encoded or not (default to not)
  • If the base64 encoded option is set, assume the file being uploaded is a base64 encoded version of the pkcs12 certificate, and decode it before installing.
  • All other parts of the upload can continue as normal.
  • base64 encoding of the body is particularly important since that encoding method is supported internally by acme.sh already.

Either of these would greatly help me manage the switches under my control. This is going to become very important for me once once Google Chrome moves to its proposed 90 day (and possibly shorter in the future) certificate validity periods. (Source: https://www.digicert.com/blog/chromes-proposed-90-day-certificate-validity-period)

This upcoming change means I would have to either move to configuring private PKI for myself and my clients, or move to automated certificate deployment (which is my preference - hence my opensouce contribution).

Thank you very much for your consideration.

1 votes

Active · Last Updated

GS1900 cannot support due to device limitation

Comments

  • Zyxel_Kay
    Zyxel_Kay Posts: 1,250  Zyxel Employee
    Zyxel Certified Network Engineer Level 2 - Nebula Zyxel Certified Network Engineer Level 2 - WLAN Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 2 - Security

    Hi @coderjoe

    Thank you for sharing your idea! Unfortunately, due to hardware limitations, the GS1900 series switches cannot support the REST API. Therefore, this feature cannot be implemented.

    We appreciate your understanding and welcome any other suggestions you may have!

    Kay

    See how you've made an impact in Zyxel Community this year! https://bit.ly/Your2024Moments_Community

  • coderjoe
    coderjoe Posts: 13  Freshman Member
    First Comment
    edited December 2024

    They already run a web server and already support file uploads from a browser. What hardware limitation is preventing a web API?

    If a web API isn't possible, could the website be updated to accept either a pks12 file format, or a separate private and public key in PEM format?

  • Zyxel_Kay
    Zyxel_Kay Posts: 1,250  Zyxel Employee
    Zyxel Certified Network Engineer Level 2 - Nebula Zyxel Certified Network Engineer Level 2 - WLAN Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 2 - Security

    Hi @coderjoe

    The REST API is an advanced extension of the switch management interface that would require comprehensive coverage for all features. Supporting the REST API would substantially increase firmware size and the Switch is required to have larger Flash and DRAM size to store and operate the firmware. The GS1900 series, being an entry-level web-managed switch, does not have the hardware capacity to accommodate these requirements.

    However, regarding your certificate management needs - the current firmware does support importing PKCS12 (.pfx/.p12) format certificates through the web interface. If you're experiencing any issues with the certificate upload process, could you:

    1. Confirm your current firmware version
    2. Share a screenshot of any error messages you're receiving
    3. Send us the certificate file via private message for further investigation

    We can work together to resolve any specific certificate upload issues you're encountering.

    Kay

    See how you've made an impact in Zyxel Community this year! https://bit.ly/Your2024Moments_Community

  • coderjoe
    coderjoe Posts: 13  Freshman Member
    First Comment
    edited January 7

    Hello Kay,

    Thank you very much for your response.
    Please note I am not asking for a comprehensitve REST API supporting all functionality, I'm only looking for a method to upload certificates which fixes the problems I'm facing with httpuploadcert.cgi

    The PKCS12 format itself is the problem. PKCS12 certificates can contain null bytes, but the acme.sh project itself is written using shell scripting and passes the request body for API calls as arguments to wget and curl.

    Passing parameters to commands in a shell is generally a problem, and the fact that PKCS12 contains raw binary data including null bytes triggers that problem. You will not see that problem in a browser, but I'm not using a browser, I'm trying to automate certificate management.

    There are potential workarounds on both ends:

    1. Make acme.sh support passing the POST body as a file, not a parameter - possible but unlikely to get merged as it would be add complexity just to support these Zyxel switches.
    2. Add a better upload API to the switch (this is option 1 in my initial request)
    3. Make the existing upload API support encoding (this is option 2 in my initial request)
    4. Support both PKCS12 files as well as PEM format (PEM format does not contain null bytes, and circumvents the problem all together)

    You will not be able to duplicate this issue only with a certificate so sending you a certificate alone will not help you.

    You can find my initial attempt at a pull request for the acme.sh project here: https://github.com/acmesh-official/acme.sh/pull/5043

  • coderjoe
    coderjoe Posts: 13  Freshman Member
    First Comment

    If you'd like a more specific example please see the following example.
    I have created a bogus pkcs12 certificate named cert.pfx.
    I have written a simple shell script which reads the certificate into a variable, and then passes that as an argument to two different commands commonly used in acme.sh to build request bodies, echo and printf.

    The script then generates a hexdump of the two files and diffs them.
    Note that the byte at offset 0x3B in the original PKCS12 certificate is a null byte.
    Note that in the generated examples that null byte is missing.

    If I try and upload the original certificate it will work, if I try and upload the example certificates they will not work because they are no longer valid.

    This is the underlying problem. The moment the PKCS12 certificate data is passed as an argument to any command in a shell, the null bytes will break the certificate. This is why I ask for either a different format, or for an upload which supports some sort of encoding to avoid the null bytes all together.

    To run the script you will need the following things installed:

    1. a shell at /bin/sh
    2. the diff command
    3. the xxd command to generate the hex output

  • darkm0de
    darkm0de Posts: 2  Freshman Member
    First Comment Friend Collector

    Hi @Zyxel_Kay, I support the request of coderjoe. I'm using a XMG1915 switch, as well as NWA50AX PRO and NWA130BE access points with certificates from letsencrypt (generated with acme.sh). This means that I have to manually upload those certificates to each device every three months. This is very inconvenient.

    Both suggested options would IMO be significantly increasing the customer value of the zyxel products.

    BR, dark-m0de