| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
The X.509 Standard
cOS Core supports digital certificates that comply with the ITU-T X.509 standard. This involves the use of an X.509 certificate hierarchy with public-key cryptography to accomplish key distribution and entity authentication. References in this document to certificates mean X.509 certificates.When distributed to another party, a certificate performs two functions:
It distributes the certificate owner's public key.
It establishes the certificate owner's identity.
A certificate acts as a digital proof of identity. It links an identity to a public key in order to establish whether a public key truly belongs to the supposed owner. By doing this, it prevents data transfer interception by a malicious third-party who might post a fake key with the name and user ID of an intended recipient.
Certificate Components
A certificate consists of the following:A public key.
The "identity" of the user, such as name and user ID.
Digital signatures that verify that the information enclosed in the certificate has been verified by a CA.
By binding the above information together, a certificate is a public key with identification attached, coupled with a stamp of approval by a trusted party.
Certificates in the cOS Core Configuration
A certificate is defined in a configuration as a logical Certificate object. The corresponding key data files for each object are stored in the cOS Core folder called certificates. The key files for Certificate objects can either come from an external source or can be created internally by cOS Core.There is a single predefined certificate object in all cOS Core configurations which is the self-signed certificate called HTTPSAdminCert and this is sent to a browser when opening a Web Interface management session using HTTPS. It is also used with SSL VPN.
A list of currently defined Certificate objects can be displayed using either the Web Interface or InControl or the CLI. To do this with the CLI, use the show command:
Device:/> show Certificate
Name Type Comments
-------------- ----- --------
HTTPSAdminCert Local <empty>To view the properties of this certificate in the CLI:
Device:/> show Certificate HTTPSAdminCert
Property Value Remarks
----------------- -------------- ---------
Name: HTTPSAdminCert
Type: Local
CertificateData: (binary data)
PrivateKey: (binary data)
CRLChecks: Enforced
CRLDistPointList: <empty>
PKAType: RSA Read-only
IsCA: No Read-only
Attribute: <empty>
Comments: <empty>
![[Note]](images/note.png) |
Note: Certificate objects cannot be added using the CLI |
|---|---|
|
The Add command cannot be used to create new certificate objects in the CLI. Instead, certificate key files are uploaded directly using the Web Interface or SCP and the upload action also creates the logical object. Alternatively, the Web Interface can be used to generate the logical object and the associated key files. |
Certificate Object Properties
The key properties of a Certificate object are the following:Type
The Type property of a Certificate object can take one of the following values:
Local
This is the type for most certificates and means both the public key and the private key of the certificate is stored on the firewall.
Local certificates can be signed or unsigned. They always consist of two files. A public key file with the filetype .cer and a private key file with the filetype .key.
Remote
This is the type for remote certificates which have the public key file residing locally in cOS Core and the private key file present on a CA server. Often, the certificate is a CA signed root certificate used to validate other certificates.
These certificates consist of just a single public key file with a filetype of .cer.
Request
If a certificate object has been created through InControl and an outstanding certificate request has been generated then this is the type. This is explained further below.
The CRL Checks property of a Certificate object determines if the certificate revocation list (CRL) for the certificate is to be checked by cOS Core and what happens if the CRL cannot be retrieved to do the checking. The possible values for this property are the following:
Enforced
This is the default and means that the associated CRL must be checked before the certificate can be used for authentication. If the associated CRL cannot be retrieved, perhaps because a CA server is offline, then the certificate will be unusable and authentication will fail.
If the certificate has no CRL associated with it then enforced checking is ignored. A self-signed certificate, such as the ones used for cOS Core management connections, do not have an associated CRL but will still have this default option selected. This is also true for any end-entity (host) certificates created using the certificate generation function in cOS Core.
Conditional
CRL checking will be performed by cOS Core provided any associated CRL is available. If the CRL cannot be accessed, perhaps because a CA server is offline, then the certificate will be used anyway.
Disabled
This causes all CRL checking to be disabled. The certificate will be used even if there is a CRL associated with it.
Further discussion of CRLs can be found later in this section.
CRL Distribution Point List
The CRL Distribution Point List property of a Certificate object can be set to a CRL Distribution Point List configuration object defined by the administrator. This can provide alternative means to perform CRL checking if it is enabled. Distribution points are described further in Section 3.9.3, CRL Distribution Point Lists.
Adding Certificates Objects to cOS Core
A Certificate configuration object is used for defining a logical certificate in cOS Core. When such an object is added, it acts as a holder for associated certificate files. Certificate files are associated with a certificate object in one of the following ways:Import External Certificate Files
Certificate files stored on the management computer's local hard disk are imported into cOS Core.
Create Certificates within cOS Core
The Web Interface can be used to create all types of certificates within cOS Core. This is explained further in Section 3.9.5, Generating Certificates.
Using InControl
InControl can be used to perform either of the following functions:
Creating Self-signed Certificates
InControl provides a way to create self-signed certificates. This duplicates the creation function in the Web Interface which is described above but provides more options.
Creating Certificate Requests
A certificate object can be created in InControl along with a certificate request. The request is then sent to a CA which returns the signed certificate file. The returned file is then imported through InControl into the certificate object to yield a CA signed certificate.
Between creating the request and importing the signed certificate file, the certificate object has a Type set to the value Request.
These functions are described in detail in an appendix of the separate InControl Administration Guide.
A CA is responsible for making sure that the information in every certificate it issues is correct. It also has to make sure that the identity of the certificate matches the identity of the certificate holder.
Note that there is an article in the Clavister Knowledge Base that describes using CA certificates issued by commercial certificate authorities at the following link:
https://kb.clavister.com/346360399
Root Certificates and Host Certificates
If a certificate is used for authentication, then it can be referred to as a Host Certificate but is sometimes referred to in cOS Core as a Gateway Certificate. The certificate will consist physically of two files, a .cer file containing the public key and a .key file containing the private key. Both files must be loaded into cOS Core.If the host certificate is CA signed then the Root Certificate provided by the signing CA will also need to be loaded into cOS Core. This is just a single .cer file containing the public key of the CA. Self-signed certificates will not have a corresponding root certificate.
Certificate Chains
A CA can also issue certificates to other CAs. This can lead to a chain-like certificate hierarchy. Each certificate in the chain is signed by the CA of the certificate directly above it in the chain. The certificates between the root and host certificates are called Intermediate Certificates and consist physically of a single .cer file containing a public key.The Certification Path refers to the path of certificates leading from one certificate to another. When verifying the validity of a host certificate, the entire path from the host certificate up to the trusted root certificate has to be available. For this reason, all intermediate certificates between the root certificate and the host certificate must be loaded into cOS Core.
Chained certificates are supported in the following cOS Core features:
Access with HTTPS to the Web Interface.
IPsec VPN.
OneConnect.
The TLS ALG.
Certificates with IPsec Tunnels
An important use of certificates in cOS Core is with IPsec tunnels. The simplest and fastest way to provide security between the ends of a tunnel is to use Pre-shared Keys (PSKs). As a VPN network grows, so does the complexity of using PSKs. Certificates provide a means to better manage security in much larger networks.Note that in cOS Core IPsec VPN, the maximum length of a certificate chain is 4. In IPsec scenarios with roaming clients, the client's certificate will be at the bottom of the certificate chain.
A certificate is not valid forever. Each certificate contains values for two points in time between which the certificate is valid. When this validity period expires, the certificate can no longer be used and a new certificate must be issued.![[Important]](images/important.png) |
Important: The system date and time must be correct |
|---|---|
|
Make sure the cOS Core system date and time are set correctly when using certificates. Problems with certificates, for example in VPN tunnel establishment, can be due to an incorrect system date or time. |
The Certificate Cache
cOS Core maintains a Certificate Cache in local memory which provides processing speed enhancement when certificates are being used by IPsec tunnels.The certificate cache is only used when certificate based IPsec tunnels are opened. The current contents can be examined with the CLI command certcache with no parameters or with the -verbose option:
Device:/> certcache -verbose
When updating certificates it can be advisable to empty the cache if an older copy might be found there. The certificate cache can be emptied in one of the following ways:
The -flush option can be used with the certcache command:
Device:/> certcache -flushThis will only remove entries which are not currently in use by an IPsec tunnel.
cOS Core is restarted. This will completely clear the cache and can be performed using the following CLI command:
Device:/> shutdown
Certificate Revocation Lists (CRLs)
A Certificate Revocation List (CRL) contains a list of all certificates that have been canceled before their expiration date. They are normally held on an external server which is accessed to determine if the certificate is still valid. The CRL is downloaded from the server and cOS Core performs the validation of the certificate against the list. The ability to validate a user certificate in this way is a key reason why certificate security simplifies the administration of large user communities.CRLs are published on servers that all certificate users can access, using either the LDAP or HTTP protocols. Revocation can happen for several reasons. One reason could be that the keys of the certificate have been compromised in some way, or perhaps that the owner of the certificate has lost the rights to authenticate using that certificate, perhaps because they have left the company. Whatever the reason, server CRLs can be updated to change the validity of one or many certificates.
Certificates will usually contain a CRL Distribution Point (CDP) field, which specifies one or more URLs with which the relevant CRL can be downloaded. In some cases, a certificate may not contain this field and the location of the CRL has to be configured manually. In cOS Core this is done by specifying a CRL Distribution Point List object and associating this with the certificate in the configuration. This is explained further in Section 3.9.3, CRL Distribution Point Lists.
A CA usually updates its CRL at a given interval. The length of this interval depends on how the CA is configured. Typically, this is somewhere between an hour to several days.
For cOS Core to check the CRL for a given certificate it may need access to an external CA server. Allowing this access is discussed in detail in Section 3.9.4, CA Server Access.
Trusting Certificates
When using certificates, cOS Core will trust a party whose certificate is signed by a given CA. Before a certificate is accepted, the following steps are taken to verify the validity of the certificate:Construct a certification path up to the trusted root CA.
Verify the signatures of all certificates in the certification path.
Fetch the CRL for each certificate to verify that none of the certificates have been revoked.
Using IPsec ID lists with certificates is described further in Section 10.3.18, Using ID Lists with Certificates.
In cOS Core, root certificates should be seen as global entities that can be reused between VPN tunnels. Even though a root certificate is associated with one VPN tunnel in cOS Core, it can still be reused with any number of other, different VPN tunnels.Other Considerations
A number of other factors should be kept in mind when using certificates:If Certificate Revocation Lists (CRLs) are used then the CRL distribution point is defined as an FQDN (for example, caserver.example.com) which must be resolved to an IP address using a public DNS server. At least one DNS server that can resolve this FQDN should therefore be defined in cOS Core.
The CRL distribution point can be contained in the certificate but cOS Core provides the ability to associate alternative CRL distribution points with a certificate. This is described further in Section 3.9.3, CRL Distribution Point Lists.
Do not get the Host Certificate files and Root Certificate files mixed up. Although it is not possible to use a Host Certificate in cOS Core as a Root Certificate, it is possible to accidentally use a Host Certificate as a Root Certificate.
Host certificates have two files associated with them and these have the filetypes .key file and .cer. The filename of these files must be the same for cOS Core to be able to use them. For example, if the certificate is called my_cert then the files my_cert.key and my_cert.cer.
Certificate File Uploading
Certificate files can be uploaded to cOS Core in one of two ways:Upload using Secure Copy (SCP).
Upload through the Web Interface or InControl.
For certificate files containing more than one certificate (certificate chains), see the note located here.
SCP Uploading of Certificate Files to cOS Core
The following example command lines show how a typical SCP command utility might upload a certificate consisting of the two files called cert-1.cer and cert-1.key. It is assumed that the firewall which has the management IP address 192.168.3.1: > scp C:\cert-1.cer admin@192.168.3.1:certificate/my_cert > scp C:\cert-1.key admin@192.168.3.1:certificate/my_cert
The certificate object name in cOS Core is my_cert for the
certificate and this is how it is referenced by other objects in the configuration.
All certificate uploads should be followed by the configuration being activated since it has been changed with new objects.
This example covers importing certificate files with the Web Interface or InControl.As mentioned earlier, there can be one or two files to upload depending on the certificate type:
Local Certificates
These certificates consist of both a public key .cer file and a private key file with the filetype .key.
Remote Certificates
A Remote Certificate is issued by a CA authority and consists of just a single file with a filetype of .cer and this is the public key. The private key is kept on the CA server. The cOS Core upload procedure consists of uploading this one file.
Example 3.52. Uploading a Certificate with the Web Interface or InControl
In this example, one or more certificate files stored on the management computer's disk are to be uploaded.
InControl
Web Interface
Example 3.53. Associating Certificates with IPsec Tunnels
To associate an imported certificate with an IPsec tunnel.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
cOS Core allows the administrator to define one or more cOS Core CRL Distribution Point List (CDPL) objects. Each list is composed of one or more entries, each entry specifying the URL of a server that can provide a Certificate Revocation List (CRL) to cOS Core for validating the certificate.
To use CDPLs in cOS Core, the following steps are used:
Load certificates into cOS Core.
Define a CRL Distribution Point List.
Associate the CRL Distribution Point List with a certificate.
Once the association is made between a certificate and a CDPL, all CRL lookups for that certificate are done using the entries in the associated CDPL. The first entry in the associated list is tried first and if that fails the second is tried, and so on. It does not matter if the certificate has its own embedded CDPL or not, the CDPL associated with it in cOS Core will always be used.
In the case of a certificate chain, only the certificate at the top of the chain needs to associated with the CDPL defined in cOS Core. This CDPL will then take precedence over any CDPL embedded in the top level certificate or any certificate at a lower level of the chain.
By forcing certificates to use the CDPL defined by the administrator instead of any CRL embedded in the certificate, the administrator can ensure access to a functioning and accessible CA server.
Example 3.54. CRL Distribution Point List
This example creates a CDPL object called my_cdpl and associates it with a certificate called my_cert with a single URL of http://crls.example.com. It is assumed that my_cert has already been uploaded into cOS Core.
The CRL checks property for the certificate will be left as the default value of Enforced which means that a CRL check against the list retrieved from the http://crls.example.com server will always be done.
Command-Line Interface
A. Configure the distribution point list:
First, add the distribution point list:
Device:/> add CRLDistPointList my_cdplNext, change the CLI context to be the list:
Device:/> cc CRLDistPointList my_cdplThen add the distribution point to the list:
Device:/my_cdpl> add CRLDistPoint URL=http://crls.example.comFinally, change the CLI context back to the default:
Device:/my_cdpl>ccDevice:/>
B. Associate the distribution point list with the certificate:
Device:/> set Certificate my_cert CRLDistPointList=my_cdplInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Configure the distribution point list:
B. Associate the distribution point list with the certificate:
Overview
Certificate validation can be done by accessing a separate Certifícation Server (CA) server. For example, the two sides of an IPsec tunnel exchange their certificates during the tunnel setup negotiation and either may then try to validate the received certificate by performing a CRL (certificate revocation list) lookup against the relevant external server.A certificate can contain a URL (the CRL Distribution Point) which specifies the validating CA server and server access is performed using an HTTP GET request with an HTTP reply. (This URL is more correctly called an FQDN - Fully Qualified Domain Name.)
If a certificate does not contain a distribution point, this can be defined separately in cOS Core by specifying a CRL Distribution Point List object and associating this with a certificate in the configuration. This is explained further in Section 3.9.3, CRL Distribution Point Lists.
Note that CRL lookup is only done with IPsec tunnels when the tunnel is initially established or when a rekey operation takes place for the tunnel.
CA Server Types
CA servers are of two types:A commercial CA server operated by one of the commercial certificate issuing companies. These are accessible over the Internet and their FQDNs are resolvable through the Internet DNS server system.
A private CA server operated by the same organization setting up the VPN tunnels. The IP address of a private server will not be known to the public DNS system unless it is explicitly registered. It also will not be known to an internal network unless it is registered on an internal DNS server.
Access Considerations
The following considerations should be taken into account for CA server access to succeed:Either side of a VPN tunnel may issue a validation request to a CA server.
For a certificate validation request to be issued, the FQDN of the certificate's CA server must first be resolved into an IP address. The following scenarios are possible:
The CA server is a private server behind the Clavister firewall and the tunnels are set up over the Internet but to clients that will not try to validate the certificate sent by cOS Core.
In this case, the IP address of the private server needs only be registered on a private DNS server so the FQDN can be resolved. This private DNS server will also have to be configured in cOS Core so it can be found when cOS Core issues a validation request. This will also be the procedure if the tunnels are being set up entirely internally without using the Internet.
The CA server is a private server with tunnels set up over the Internet and with clients that will try to validate the certificate received from cOS Core. In this case, the following must be done:
The same steps should be followed if the other side of the tunnel is another firewall instead of being many clients.
The CA server is a commercial server on the Internet. In this, the simplest case, public DNS servers will resolve the FQDN. The only requirement is that cOS Core will need to have at least one public DNS server address configured to resolve the FQDNs in the certificates it receives.
It must be also possible for an HTTP PUT request to pass from the validation request source (either the firewall or a client) to the CA server and an HTTP reply to be received. If the request is going to pass through the firewall, the appropriate entries in the cOS Core IP rule set need to be defined to allow this traffic through.
IP rule set entries are not required if it cOS Core itself that is issuing the request to the CA server. Actions taken by cOS Core are trusted by default. This is a general rule that also applies to DNS resolution requests issued by cOS Core.
The diagram below illustrates the placement of the various components involved in CA server access.
In a VPN tunnel with roaming clients connecting to the Clavister firewall, the VPN client software may need to access the CA server. Not all VPN client software will need this access. In the Microsoft clients prior to Vista, CA server requests are not sent at all. With Microsoft Vista validation became the default with the option to disable it. Other non-Microsoft clients differ in the way they work but the majority will attempt to validate the certificate.Placement of Private CA Servers
The easiest solution for placement of a private CA server is to have it on the unprotected side of the firewall. However, this is not recommended from a security viewpoint. It is better to place it on the inside (or preferably in the DMZ if available) and to have cOS Core control access to it.As explained previously, the address of the private CA server must be resolvable through public DNS servers for certificate validation requests coming from the Internet. If the certificate queries are coming only from the Clavister firewall and the CA server is on the internal side of the firewall then the IP address of the internal DNS server must be configured in cOS Core so that these requests can be resolved.
Turning Off validation
As explained in the troubleshooting section below, identifying problems with CA server access can be done by turning off the requirement to validate certificates. Attempts to access CA servers by cOS Core can be disabled with the Disable CRLs option for certificate objects. This means that checking against the CA server's revocation list will be turned off and access to the server will not be attempted.cOS Core provides the ability to generate new Certificate objects with the associated key files within the firewall, without uploading files from an external source. The certificates generated can be any of the following types:
This is a CA root certificate with public and private key files that can be used to sign other certificates generated by cOS Core.
The default certificate key size is 384 bits and the default validity time is 5475 days.
Using cOS Core generated CA certificates, where the firewall itself acts as the CA, is discussed further in an article in the Clavister Knowledge Base at the following link:
Intermediate CA Signed Certificates
This type of certificate must have its Issuer Certificate set to a CA signed certificate that may be also generated by cOS Core (so the private key is available). It can then be used to sign end-entity certificates.
The default key size is 384 bits and the default validity time is 3650 days.
Self-signed Certificates
These are standard self-signed certificates that do not require signing by a CA certificate.
The default key size is 192 bits and the default validity time is 365 days.
End-Entity Certificates
These are host certificates that can be used for multiple purposes and that are signed by a CA certificate or intermediate certificate.
The default key size is 192 bits and the default validity time is 365 days.
Each of the above types uses a default signature algorithm of SHA-256 and an elliptic curve (EC) key type but these can be changed if required at the time of creation.
The IKE Authentication Option for End-entity and Self-signed Certificates
The end-entity and self-signed certificate types include an option called IKE Authentication which is disabled by default. This option should be enabled if a certificate is to be used as an end-entity certificate with IPsec tunnels. Enabling it will enable the relevant usage flags in the certificate that are required by IKE.The CA Certificate Path Length
The Path Length Constraint can be set to determine the longest allowable certificate chain to an end-entity certificate. The values can be one of the following:The default value of zero means that there can be no intermediate certificate between the CA root certificate and an end-user certificate.
A value of one means that there can be at most one intermediate certificate in the chain between the CA certificate and an end-user certificate.
Any value greater than one means that there can be at most that number of intermediate certificates in the chain between the CA certificate and an end-user certificate.
Notes About Certificate Generation
The following points should be noted about certificate generation in cOS Core:The certificate generation function is available in the Web Interface only. It is not available in the CLI.
The certificate files generated can be downloaded from the firewall through the Web Interface by pressing the download button in the object properties page for a certificate. Alternatively, certificate files can be downloaded using SCP from the certificate folder in cOS Core. SCP downloading examples can be found in Section 2.1.8, Using SCP.
No CRL (revocation list) feature is available, although the CRL checks property for all generated certificates will always be set to a value of Enforced.
Once a certificate is generated, the generation parameters cannot be changed. Instead, a new certificate must be created.
Certificate generation can require significant processing resources, particularly with larger key sizes. The feature should therefore be used with caution when generation is done at the same time that live traffic is flowing.
Note that the Clavister InControl product can be used to create self-signed certificates without requiring firewall resources.
firewall generated certificates, where the firewall acts as the CA server, can be used with IPsec roaming clients. Using them with the Windows VPN client is discussed in a Clavister Knowledge Base article at the following link:
Example 3.55. Creating a CA Certificate
This example will create a new Certificate object called my_ca_cert which will be a CA root certificate with its associated public key and private key files.
The allowable path length will be set to a value of 1, meaning that a maximum of one intermediate certificate can be used between the CA certificate and an end-entity certificate in a certificate chain.
Web Interface
ACME Protocol for Certificate Management
The Automatic Certificate Management Environment (ACME) protocol in cOS Core makes it easier to issue, renew and maintain certificates helping to manage the public key infrastructure. ACME allows secure, automatic communication between the client and the certificate authority servers, keeping services trusted without needing manual handling. This section will show you how to set up an ACME account in cOS Core and explain how to automate certificate management.Clavister ACME Overview
The firewall ACME client follows the ACME protocol as defined in RFC-8555 and currently supports interaction with the Let's Encrypt™ and BuyPass™ certificate authority (CA) servers as well as the option to manually specify a URL to an ACME compliant server.In order to use the client and be able to order certificates from the CA server, an account is required. The account details are entered in cOS Core, which then creates the account in the CA server. The account is used to identify the client to the CA server, and to help maintain the certificates. When creating the account, the user can also create new orders for certificates or leave them for a later stage.
The account and any certificate order created will be requested from the CA server after successful activation of the configuration changes. A certificate order consists of a certificate request, intended to be used for a specific host (host.example.com ) or hosts (host.example.com, host_alias.example.com, etc). During the order request process, the CA server (or a server under the control of the CA) will issue one or more HTTP challenges to verify the existence of the domain. The ACME Client will need to intercept and respond to these challenges.
In order to intercept the challenge, the simplified (automatic handling) option is used by default. The alternative option is to set up a reverse proxy policy controlling the HTTP protocol on port 80. For more details see the challenge settings .
After all challenges have been accepted by the CA, the ACME client will download the certificate chain and add its elements as individual key ring objects (this will cause a reconfiguration event to trigger).
The leaf (also known as end-entity) certificate in the chain is identified by the name given to the certificate, and the intermediate nodes are identified by the given name followed by "_C#" where the "#" is the certificate order in the chain counting from the leaf (ex: WebServer_C1).
After the certificate ordering process is completed, a timer is started. When triggered, this timer will go through the existing list of certificates for the account and check if any need to be renewed. Providers of certificates using the ACME protocol provide certificates with short validity, normally around 3 to 6 months, hence regular renewals are required. The renewal process is automatically attempted 30 days prior to end of validity. This 30 days prior to end of validity is used to prevent any downtime scenario that could cause issues with an expiring certificate.
![[Warning]](images/warning.png) |
Warning: Using manual restart in CLI |
|---|---|
|
If the CLI command "ACME -restart" is executed, it would trigger an immediate request of all certificates regardless of the configured Renewal Time Range. |
|
Note: Changing certificate properties will trigger certificate requests |
|---|---|
|
If changes are made in the configuration to a certificate property in the ACME client, it will trigger an immediate request of all certificates similar to when "ACME -restart" is executed in the CLI regardless of the configured Renewal Time Range. |
The simplified challenge option
When selecting the challenge method to use, the default selection is the simplified option. But what does it do?The simplified option listens on all interfaces and networks and automatically handles the incoming ACME challenge response from the ACME server without the need to create any additional IP policy. It is similar to e.g. "IPsecBeforeRules" where IPsec related traffic is automatically picked up by cOS Core without the need for an IP Policy to allow it.
In order for cOS Core to automatically pick up the challenge response from the ACME server, the following must be true:
If the above is not true, the automatic rule will not trigger and the incoming HTTP packet will be forwarded to e.g. the IP ruleset for further processing. And if no match is found, the packet will be dropped.
Summary
Use simplified for an automatic handling of the ACME certificate download and renewal processes.
Use Reverse proxy if the client for the certificate is another server behind the firewall that you have an existing reverse proxy rule for or if you want more control over the source interface and network that the ACME challenge is expected to arrive on.
|
Note: Existing Reverse Proxy Policy |
|---|---|
|
Any existing reverse proxy policy can be used, if it includes protocol HTTP and port 80. |
|
Warning: Sharing port 80 |
|---|---|
|
Since the ACME server always uses HTTP port 80 for it's challenges, cOS Core needs to setup a listening socket in order to intercept the challenge and respond to it. Therefore ACME will fail to respond if the socket is already in use by something else, such as:
|
ACME Accounts
An ACME account is used to handle the automatic renewal and management of certificates via the ACME protocol. This account contains various settings required for the ACME protocol to work properly.General Options
The following options can be configured for an ACME accounts entity:A symbolic name for the account name. Used as entity identifier but also used as a reference in log messages.
A selection if you want to use the standard Let's Encrypt™, BuyPass™ URL or if a manual/custom URL should be used to perform the certificate request.
Keytype used to authenticate the client with the ACME server (e.g. ECC 256 or RSA 2048).
ACME Account Contact Information.
Automatically accepts the terms of service sent by the server. This option may be mandatory for some certificate providers.
A selection if you want to use the Simplified or Reverse Proxy. The Simplified option automatically handles the challenge from the ACME server without the need for a Reverse Proxy Policy. If Reverse Proxy is selected, a Reverse Proxy Policy needs to be created. For more information about Reverse Proxy configuration see Section 3.6.12, Reverse Proxy and in the configuration example further down.
A selection of start and end hours when certificate renewal operations is allowed to be performed.
Certificate Management Options
The following options can be configured for an automated request certificate:A list of domains that the certificate needs to authenticate.
Key type for the certificate (e.g. Elliptic Curve).
These are all additional parameters that can be inserted in the automatic certificate request query.
Example 3.56. Setting up certificate auto-renewal using ACME
In this example, an ACME account will be configured in order for cOS Core to perform automatic certificate renewals.
The example will be performed using a standard configuration with LetsEncrypt™ as the selected provider. Many options are not mandatory and the example will be kept at a base functionality level. If not specified, the default option or action is selected.
Command-Line Interface
A. ACME Account Creation:
Device:/> add ACMEAccount LetsEncrypt
Email=example@example.com
AcceptTerms=yesA-1. Add ACME Certificate Management:
Device:/> cc ACMEAccount LetsEncryptDevice:/> add ACMECertMgmt Cert_ACME
Domains=domain5.example.comThe above will create an ACME account which will order certificates related to the domain5.example.com domain automatically. The ordered certificates will also be renewed later, when required. Alternative domain names can be added if desired.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. ACME Account Creation:
Example 3.57. Setting up certificate auto-renewal using ACME and Reverse Proxy
In this example, an ACME account and a Reverse Proxy IP Policy will be configured in order for cOS Core to perform automatic certificate renewals.
The example will be performed in two parts, the first part consists of ACME account creation and in the second part the Reverse Proxy IP policy is created. Many options are not mandatory and the example will be kept at a base functionality level. If not specified, the default option or action is selected.
Command-Line Interface
A. ACME Account Creation:
Device:/> add ACMEAccount LetsEncrypt
Email=example@example.com
AcceptTerms=yes
ChallengeType=ReverseProxyA-1. Add ACME Certificate Management:
Device:/> cc ACMEAccount LetsEncryptDevice:/> add ACMECertMgmt Cert_ACME
Domains=domain5.example.comThe above will create an ACME account which will order certificates related to the domain5.example.com domain automatically. The ordered certificates will also be renewed later, when required. Alternative domain names can be added if desired.
B. Reverse Proxy IP Policy Creation:
Device:/> add ReverseProxyPolicy Name=MyLetsEncrypt_Proxy
SourceInterface=wan
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=http
EnableACME=YesThe above will create a Reverse Proxy IP Policy that is needed to intercept the challenge from the ACME server. In order to intercept the challenge cOS Core needs to listen on port 80 for incoming http requests. If http is used by something else such as a web server or other, a mapping in the Reverse Proxy IP Policy needs to be added.
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. ACME Account Creation:
B. Reverse Proxy IP Policy Creation:
The above will create a Reverse Proxy IP Policy that is needed to intercept the challenge from the ACME server. In order to intercept the challenge cOS Core needs to listen on port 80 for incoming http requests. If http is used by something else such as a web server or other, a mapping in the Reverse Proxy IP Policy needs to be added.
