lb certificate
The lb certificate command manages the server certificates that the vServices present. A certificate can come in five ways: it is taken automatically with ACME, it is uploaded by hand, it is imported from a PFX file, it is signed by an external CA with a request created on the device, or it is created with the internal CA of TR7 itself. Its panel equivalent is the SSL/TLS Certificates screen.
Command Summary
In the add command the first field written is type
How the certificate will come is selected first; the name and the other fields are asked for after it.
Where the Certificate Comes From
| Command | What it does | Where the key is created |
|---|---|---|
add type acmeSh | Takes it automatically from the ACME server and renews it before it expires | On the device |
add type manual | Saves the certificate and key text at hand | Outside |
add type pfx | Imports the certificate and the key in the PFX file | Outside |
create-csr | Creates a key and a certificate request (CSR) on the device; the request is signed by an external CA and it is completed by pasting the signed certificate into the record. The key does not leave the device | On the device |
add type csr | Creates a record of the same type by hand | — |
issue-internal | Creates a leaf certificate from the internal intermediate CA with a certificate profile; a ledger row that carries on the automatic renewal is opened as well | On the device |
renew-internal | Renews a certificate created internally right away | On the device |
add — The Required Fields
| Order | Field | Status | Value |
|---|---|---|---|
| 1 | type | Required | acmeSh · manual · pfx · csr |
| 2 | name | Required | The name of the record |
| 3 | cert · key | Conditionally required | Only in the manual type: the certificate and key text |
| 3 | pfxFile | Conditionally required | Only in the pfx type: the PFX file |
acmeSh — an automatic certificate with ACME
| Field | What it does | What is written after it |
|---|---|---|
--acmeShServer | Selects the ACME server from which the certificate will be taken | letsencrypt (default) · zerossl · sslcom · google |
--acmeShEmailAddress | Gives the email address to be used in the ACME registration | An email address |
--acmeShChallengeType | Selects how the ownership of the domain name will be proven | http01 (default) · dns01 |
acmeShDnsProviderId | Selects the provider to be used in the DNS verification | The lb acme-dns-provider record; when --acmeShChallengeType dns01 is written it becomes required and is written without a prefix right after it, even if there is a -- in the line |
--acmeShDomains.N.domain | Writes the domain name that the certificate will cover | A domain name; each with its own index |
--acmeShDomains.N.poolId | Selects over which vService the HTTP verification will be done | A vService record |
--acmeShKeyLength | Selects the length of the key to be created | ec-256 (default) · ec-384 · ec-521 · 2048 · 3072 · 4096 |
--acmeShRenewThreshold | Determines how many days before the expiry it will be renewed | 7 (default) · 14 · 30 · 45 · 90 · 180 days |
--acmeShDeviceId | Selects on which cluster member the operation will be executed | The cluster id (default 1) |
--acmeShZoneId | Selects from which virtual device the operation will be done | The virtual device; the default is the device on which the command runs |
--acmeShNamespace | Selects from which route table the operation will go out | A route table (default 1) |
--acmeShEabId · --acmeShEabHmac | Carries the external account binding information that the server asks for | The id and the HMAC given by the provider; they open only while --acmeShServer is sslcom, google or zerossl |
manual — uploading by hand
| Field | Status | What it does | What is written after it |
|---|---|---|---|
cert | Required | Saves the server certificate | The PEM text; it is written inside double quotes |
key | Required | Saves the private key of the certificate | The PEM text |
--password | Optional | Gives the password of the encrypted key | The password of the key |
pfx — importing from a PFX file
| Field | Status | What it does | What is written after it |
|---|---|---|---|
pfxFile | Required | Takes the file that contains the certificate and the key | The PFX file on the device |
--password | Optional | Gives the password of the PFX file | The password of the file |
The Chain Fields
These fields are common in the manual, pfx and csr types; they determine how the intermediate and root certificate will be completed.
| Field | What it does | What is written after it |
|---|---|---|
--intermediateCertProfile | Takes the intermediate certificate from a ready CA profile | A CA profile record |
--extraIntermediateCertProfiles.N | Adds additional intermediate certificates to the chain | CA profile records; they open only when --intermediateCertProfile is given |
--intermediateCert | Writes the intermediate certificate directly | The PEM text; it opens only when --intermediateCertProfile is left empty |
--rootCertProfile | Takes the root certificate from a ready CA profile | A CA profile record |
--extraRootCertProfiles.N | Adds additional root certificates to the chain | CA profile records; they open only when --rootCertProfile is given |
--rootCert | Writes the root certificate directly | The PEM text; it opens only when --rootCertProfile is left empty |
--allowDownload | Turns on the certificate being downloadable from the interface | true · false (default false) |
The fields derived from the certificate are not written
The four fields below appear in the completion list but their values are filled in by the server while the certificate is being parsed; writing them by hand is not an expected use.
| Field | What it does | What is written after it |
|---|---|---|
--certContent | Holds the content of the parsed certificate | The server fills it in; it is not written by hand |
--certDnsNames.N | Holds the DNS names that the certificate covers | The server fills it in; it is not written by hand |
--infoArr.N | Holds the additional key details parsed from the certificate | The server fills it in; it is not written by hand |
--certEku.N | Holds the extended key usage of the certificate | The server fills it in; it is not written by hand |
create-csr — Creating a Certificate Request
It creates a private key on the device and a request to be sent to the CA. The key does not leave the device; the record is completed when the certificate signed by the external CA is pasted into the record.
| Order | Field | Status | What it does | What is written after it |
|---|---|---|---|---|
| 1 | name | Required | Gives a name to the record | The name of the record |
| 2 | cn | Required | Determines the main name of the certificate | The Common Name, for example portal.kurum.com.tr |
| — | --o | Optional | Writes the name of the organization | The Organization value |
| — | --ou | Optional | Writes the name of the unit | The Organizational Unit value |
| — | --c | Optional | Writes the country code | A two-letter country code, for example TR |
| — | --san | Optional | Writes the additional names that the certificate will cover | Comma-separated names |
| — | --keyAlgo | Optional | Selects the key algorithm | rsa2048 (default) · rsa3072 · rsa4096 · ecP256 · ecP384 |
| — | --allowDownload | Optional | Turns on the key being downloadable from the interface | true · false (default false) |
issue-internal — Creating a Certificate with the Internal CA
It creates a leaf certificate from the internal intermediate CA according to a certificate profile. As a result an ordinary certificate record and a ledger row that carries on the automatic renewal are formed.
| Order | Field | Status | What it does | What is written after it |
|---|---|---|---|---|
| 1 | name | Required | Gives a name to the record | The name of the record |
| 2 | caId | Required | Selects the CA that will sign the certificate | An intermediate CA created with lb ca |
| 3 | profileId | Required | Selects the profile that brings the settings such as the lifetime and the usage | A Certificate Profiles record |
| 4 | cn | Required | Determines the main name of the certificate | The Common Name |
| — | --san | Optional | Writes the additional names that the certificate will cover | Comma-separated names |
| — | --allowDownload | Optional | Turns on the key being downloadable from the interface | true · false (default false) |
renew-internal — Renewal
It renews a certificate created internally right away: a new key and a new serial number are created, the bound record is updated in place, and the service is reloaded with the new certificate.
| Order | Field | Status | What it does | What is written after it |
|---|---|---|---|---|
| 1 | certId | Required | Selects the certificate to be renewed | A certificate record created internally |
Examples
Binding to a vService
Updating and Deleting
Things to Know
- It should be treated as if the type does not change later. With whichever type the record was created, its fields open accordingly; in order to get a certificate in another way, creating a new record is safer.
- The renewal asks for confirmation. Before
renew-internalruns, a confirmation screen saying that the live certificate will change and the service will be reloaded comes. - The CSR flow is two steps.
create-csrcreates only the key and the request; the record is not completed until the certificate signed by the external CA is pasted into the record. The key does not leave the device in this process. - The
buypassserver no longer issues certificates. The value stays in the list only so that the old records that point to that server can be edited; it should not be selected in new records. - The EAB information is not asked for on every server.
--acmeShEabIdand--acmeShEabHmacopen only on thesslcom,googleandzerosslservers. - The PEM texts require quotes. Since the certificate and key texts contain line breaks and spaces, they are written inside double quotes.
