SSL Certificates that secure SSL (encrypted) communication between your iPad and printer are the source of your observed issue. While Certificate warnings should not be routinely ignored, understanding precisely what is going-on allows you to make an informed judgement - and in this case dismiss the warning.
Without delving too deeply into to technical complexities of TLS/SSL (this being an advanced topic) each time that you power-cycle your printer, the printer automatically generates a new self-signed Certificate with which to encrypt the printing connection. Being self-signed and without a trusted-root, your iPad (and other devices) cannot validate the authenticity of the Certificate - and for this reason you will see the warning that you describe. Selecting Continue should allow you to click-through any associated security warnings.
As long as your Printer remains powered-on, your Printer's certificate won't change and will continue to be trusted until such time as it is next power-cycled.
For Enterprise/Business environments, where the IT Department may use their own trusted Certificate Authority (CA), it is possible to generate Certificates that are verifiable against the issuing or trusted CA. These certificates are installed on end-user client devices - and in this case the printer. SSL/TLS communication between client and endpoint devices are thus fully secured and verifiable against the local Certificate Authority (CA). As long as the validity of the associated certificates can be verified as both valid and authentic, no warmings will be seen.
Any SSL/TLS warnings that are seen when accessing commercial services or external websites should be taken seriously - as errors of this nature suggest that the website/service (or communication to it) is either misconfigured by the operator, or has been compromised (e.g. a fake website).
In summary, what you see when accessing your local printer is benign - and by design cannot be suppressed. Understanding what is happening and why allows you to make an informed decision to proceed if deemed safe (in this case, it is). SSL/TLS alone merely encrypts communication - and alone does not suggest that the service is safe or should be trusted. Bad Actors use SSL/TLS along with everyone else.
Establishing verifiable "trust" is designed to reduce the likelihood of communicating with something that shouldn't. Achieving this is a domestic setting is complex and beyond the capabilities of most end-Users - and is impractical most domestic settings.
The above is intended to be a relatively simple and understandable explanation of what is happening and why. It is not intended to be an in-depth technical tutorial on SSL/TLS communication or detailed description of how CA's operate in general. If you are interested, there are many online resources that can offer a more detailed primer on these topics.
