--- title: "How to sign a request" slug: "certificates-flow-how-to-sign-request" updated: 2026-11-06T18:56:49Z published: 2026-11-06T18:56:49Z canonical: "docs.senhasegura.io/certificates-flow-how-to-sign-request" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt > Use this file to discover all available pages before exploring further. # How to sign a request This document provides information on how to sign a request. The signature of a request ensures the authenticity and integrity of the data, verifying its origin and preventing changes during transmission. ## Requirements An unsigned request. ## Sign a request To sign a request, see the following steps: 1. On **Segura™ Platform**, in the navigation bar, hover over the **Products menu** and select **Certificate Manager**. 2. In the side menu, select **Requests > SSL/TLS**. 3. In the desired request, click **Actions > Request signature**. 4. In the **General** tab, enter the following information: 1. In the **Self-signed? *** field, select to self sign the request. It is recommended for devices that communicate only with others located on internal networks. 2. In the **Choose CA** field, select the CA that will sign the request. This field is only available after selecting **No** in the **Self-signed? *** field. If the selected CA uses a Network Connector, the text **Uses Network Connector: `<agent>`** appears next to this field, naming the connector configured on the CA, or **default connector** when none is selected. This text appears only for CAs that have the **Use Network Connector?** field (DigiCert, GlobalSign, and Let's Encrypt). It never appears for a Microsoft CA, even if its device has a Network Connector. 3. In the **Justification *** field, enter a justification for signing the request. 4. In the **Reason *** field, select one of the registered reasons. 5. In the **Governance Code** field, enter a governance code to help with the internal organization or location of the request. 5. Optional: For GoDaddy certificates, go to the **GoDaddy** tab and enter the following information: If the product is not compatible with the request, Segura® rejects it. - For a new certificate request, in the **Product** field, select the GoDaddy product. The field is required, comes pre-selected, and lists only domain-validated (DV) products. - For a renewal request, in the **Period *** field, enter the renewal period of your GoDaddy product. 6. Optional: For DigiCert certificates, go to the **Additional information** tab and enter the following information: If the CA's Network Connector agent is unreachable, an alert explains why, and the **Organization**, **Product**, **Contact**, and **Domain validation method** fields are disabled. The account data loads only when you select the CA, so after the agent reconnects, select the CA again or reopen the form to enable the fields. The alert also appears if the tunnel is unavailable, or if DigiCert denies access. 1. In the **Organization** field, select the organization associated with the certificate. 2. In the **Product** field, select the DigiCert product for this certificate. 3. In the **Contact** field, select the contact for the certificate request. 4. For domain-validated (DV) certificates, in the **Domain validation method** field, select **Email**, **DNS CNAME**, **HTTP**, or **DNS TXT**. 7. Optional: For Let's Encrypt certificates, go to the **Validation** tab and enter the following information: If the Let's Encrypt CA uses a Network Connector, a help icon next to **Validation type** explains that the connection routes through it. 1. In the **URL** field, enter the URL Segura® uses to publish the domain-validation file. 2. In the **Validation type** field, select **FTP**, **FTPS**, or **SFTP**. The default is **SFTP**. 3. In the **Remote path** field, enter the path on the web server where Segura® publishes the validation file. 4. In the **Port** field, enter the port for the connection. The default port is 22, also for FTP and FTPS: for those, change it to the port of your server, usually 21 for FTP or 990 for FTPS. 5. Optional: Check **Use a registered credential to access the domain** and, in **Access credential registered in the system**, select the credential to use. If you do not use a registered credential, enter the user name and password for the connection in the **Username** and **Password** fields. 8. Optional: For Microsoft CA certificates, go to the **Signing template** tab and, in the **Signing template** field, enter the certificate template. The default is `webserver`. Attention Automatic renewal does not keep the template of the original certificate. The renewed certificate is signed with the `webserver` template. More information in [How to integrate with a Microsoft CA](/v4-2/docs/clm-integrate-microsoft-ca#certificate-template). 9. Click **Continue**. 10. In the **Review** tab, review all information entered previously and click **Save**. Alert For GoDaddy certificates, renewal will consume an available renewal credit or applicable account balance. If a DigiCert CA rejects the credential, the error message identifies the cause (for example, an invalid account ID, user, or API key permission) instead of showing DigiCert's raw technical response. A communication failure with DigiCert shows the specific cause instead of a generic connection error. While a Let's Encrypt request awaits domain validation, it stays in the **Waiting signature** status. The [Validation guidelines](/v4-2/docs/certificate-manager-reference-certificate-requests#validation-guidelines-screen) screen shows, in the **Status** column, the next automatic validation check and the date the request expires. If validation is not completed within 7 days of the first signing attempt, the request moves to **Error signing**. For requests created before this behavior, the 7 days count from the request creation. The status message shows the 7-day limit was exceeded and Let's Encrypt's last message. The reason is always recorded in the [Signature Debug](/v4-2/docs/clm-signature-debug) report, even when detailed logging is turned off. In the [SSL/TLS requests](/v4-2/docs/certificate-manager-reference-certificate-requests) report screen, the specific request will have its status updated to **Signed**.