HTTPS Self-Signed or with Custom CA

Guide for Make Custom Apps to connect securely to HTTPS services using self-signed or custom CA certificates.

This guide is relevant only for special cases where it is reasonably expected that the application may need to communicate with third-party servers using HTTPS connections that rely on either a self-signed certificate or a custom certificate authority (CA) instead of a widely trusted public CA.

If your Custom App only interacts with services that use publicly trusted certificates, you can safely ignore this guide.

---

BREAKING CHANGE – Coming in Fall 2025

Dear Make Users and Custom App Developers,

We would like to inform you in advance about an upcoming change that will strengthen our HTTPS validation policy. Beginning in Fall 2025, Make will begin blocking untrusted HTTPS connections by default.

If your servers are using self-signed or otherwise untrusted certificates, please carefully review the guide below and update your Custom App accordingly.

While this change may affect a small number of edge-case usages, we are confident that it brings a clear security benefit to all customers.

---

Common Certificate Issues

1. Self-signed certificate Often used in internal or test environments. These certificates are created and signed by the server itself, not by a Certificate Authority (CA).

2. Custom Certificate Authority (CA) Common in company-internal tools and services. Organizations may run their own CA and issue certificates for internal domains. These CAs are not globally trusted, so the trust must be added manually.

3. Expired certificate A certificate that has passed its validity period will be treated as invalid. Even if it was originally issued by a trusted CA, it is no longer accepted unless renewed.

4. Other certificate problems Examples:

   • Invalid CN/SAN: The domain name does not match the one in the certificate.

   • Incomplete chain: Missing intermediate certificates required for full trust.

   • Unknown or weak signature algorithms: Outdated encryption methods (e.g. MD5).

---

Behavior & Solutions - Quick Reference

Behavior until Fall 2025

By default, Make allows connections to HTTPS services even when the certificate is invalid or untrusted. In such cases, the platform generates a warning for each affected scenario module.

Certificate Issue	Default Behavior
✅ Public HTTPS certificate	✅ Connection allowed
❗ Self-signed certificate	🔔 Connection allowed, produces warning
❗ Custom CA certificate	🔔 Connection allowed, produces warning
❗ Expired certificate	🔔 Connection allowed, produces warning
❗ Invalid or weak certificate	🔔 Connection allowed, produces warning

⚠️ Breaking Change – Behavior from Fall 2025

Starting from this date, Make will block HTTPS connections by default if the certificate is untrusted or invalid. To maintain functionality, follow the recommended steps in your Custom App:

Certificate Issue	Default Behavior	Recommended Custom App improvement	Behavior After the Custom app improvement
✅ Public HTTPS certificate	✅ Connection allowed	✅ No action needed	✅ Connection allowed
❗ Self-signed certificate	❌ Connection blocked	🔧 Upload the self-signed certificate	✅ Connection allowed
❗ Custom CA certificate	❌ Connection blocked	🔧 Upload the custom CA certificate	✅ Connection allowed
❗ Expired certificate	❌ Connection blocked	❌ No fix in Custom App is possible	❌ Connection blocked
❗ Invalid or weak certificate	❌ Connection blocked	❌ No fix in Custom App is possible	❌ Connection blocked

---

Implementation in Custom Apps: Upload Custom CA/Certificate

Your Custom App can be extended to accept a custom certificate (trusted CA or self-signed) for the case of self-signed certificate or custom CA.

💡 Best practice: Always prefer using a certificate issued by a globally trusted CA.

Define Certificate Statically

Add the trusted custom CA certificate (or self-signed certificate) to both the base and connection JSON configurations of the Custom App.

Note: You need to add it in both places, because connections do not inherit configuration from the base code.

Example:

// custom app's base
{
    // Your default base config like `baseUrl`, `headers`, `response`, `log`, ...
    "baseUrl": "https://some-my-private-service.example.com/api",

    // Add the property `ca` with public cert of your own CA or of your self-signed cert.
    "ca": "-----BEGIN CERTIFICATE-----\nMIIDeTCCAmGgAwIBAgIJAOSe0iZEklcXMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV\nBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1TYW4gRnJhbmNp\n... (certificate truncated in example) ...\ny4qocoQVErLCN+R1VscdmTgNgIypce6+Dirco8Skh5/V7KgLXHUZ7BPyaxJpzxxM\nvJEZ/1G0g7NopNIOKcCBBneqjir85QUYQ9DZDNY=\n-----END CERTIFICATE-----"
}

// connection's communication
{
    "ca": "-----BEGIN CERTIFICATE-----\nMIIDeTCCAmGgAwI ...", // certificate truncated in example

    // ... and other config like `url`, `headers`, `response`.
}

The example above shows the principle of how to configure it. But defining the CA cert statically is useful in limited cases, where the certificate is fixed and known in advance.

Ask user for Certificate Dynamically

Let the customer enter the certificate themselves during the connection creation. This is useful if you need to give your Custom App the flexibility to connect to any instance on the internet (for example, by having the customer enter their own URL).

For the implementation, add a new mappable parameter with type: "cert" into the Connection and then reference it in both the base and the connection's communication.

Example:

// connections's mappable parameters
[
    // Ask user for extra CA of HTTPS connection
    {
        "name": "ca",
        "label": "Trusted Custom CA / Self-Signed Certificate",
        "help": "Upload a certificate if an HTTPS server uses custom Certificate Authority (CA) or a self-signed certificate. This allows to trust connections to that server.",
        "type": "cert",
        "advanced": true, // display only after click to "Show advanced settings"
        "editable": true, // allow to enable/disable in connection edit

    },
]

// connection's communication
{
    // use the user uploaded certificate in the Connection
    "ca": "{{connection.ca}}",

    // ... other config like `url`, `headers`, `response`.
}

// custom app's base
{
    // use the user uploaded certificate in the rest of custom app
    "ca": "{{connection.ca}}",

    // ... and other config like `baseUrl`, `headers`, `response`.
}

Tip: Download the CA Certificate from the Existing HTTPS Service

The following Linux / macOS command can help you retrieve the required CA certificate (or self-signed certificate) from an existing HTTPS service. In the first line of the command below, replace YOUR_DOMAIN.com with your actual domain, then copy the certificate string, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- sections.

# Replace YOUR_DOMAIN.com below with your actual domain
openssl s_client -showcerts -connect YOUR_DOMAIN.com:443 </dev/null 2>/dev/null | \
awk '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/' | \
awk 'BEGIN{n=0} 
     /BEGIN CERTIFICATE/{n++; out[n]=$0; next} 
     /END CERTIFICATE/{out[n]=out[n] ORS $0; next} 
     {out[n]=out[n] ORS $0} 
     END{print out[n]}'

HTTPS with Invalid or Expired Certificate

Due to security implications, it is not possible to configure the Custom App to connect to an HTTPS service if the certificate is invalid or expired.

The only secure solution in this case is to replace the invalid or expired certificate on the server. This process lies outside of Make's control and must be coordinated directly with the third-party technical support team responsible for the affected server.

rejectUnauthorized Directive Deprecation Notice

The directive rejectUnauthorized: false usable in Custom Apps for allowing connections to untrusted HTTPS servers with security issues is being deprecated and will be removed in the future.