16.2. CA Server Access

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

Overview

Certificate validation can be done by accessing a separate Certifícate Server (CA). For example, the two sides of an IPsec tunnel would exchange their certificates during the tunnel setup negotiation and either side might then try to validate the received certificate by accessing a CA server.

A certificate contains a Fully Qualified Domain Name (FQDN) which specifies the textual address of the validating CA server as well as the protocol used for accessing the server. For example, server access could require an HTTP request or possibly an LDAP request.

CA Server Types

CA servers can be one of the following two types:

A Commercial CA Server

Commercial CA servers are operated by one of the commercial certificate issuing companies. These are accessible over the public Internet and their FQDNs are resolvable through the public Internet DNS server system.
A Private CA Server

A private CA server will be operated by the same organization setting up the VPN tunnel. The IPv4 or IPv6 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.

For LTE scenarios in a telecoms environment, a private CA server is most often used, with server requests sent using the LDAP protocol. However, the protocol used is determined by the settings within the certificate.

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:
1. The CA server is a private server behind the Clavister NetShield Firewall and the tunnels are set up over the public Internet but to clients that will not try to validate the certificate sent by cOS Stream.
  
  In this case, the IPv4 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 Stream so it can be found when cOS Stream issues a validation request. This will also be the procedure if the tunnels are being set up entirely internally without using the public Internet.
2. The CA server is a private server with tunnels set up over the public Internet and with clients that will try to validate the certificate received from cOS Stream. In this case the following must be done:
  1. A private DNS server must be configured so that cOS Stream can locate the private CA server to validate the certificates coming from clients.
  2. The external IP address of the Clavister NetShield Firewall needs to be registered in the public DNS system so that the FQDN reference to the private CA server in certificates sent to clients can be resolved. For example, cOS Stream may send a certificate to a client with an FQDN which is ca.company.com and this will need to be resolvable by the client to a public external IP address of the Clavister NetShield Firewall through the public DNS system.
  The same steps should be followed if the other side of the tunnel is another firewall instead of being many clients.
3. The CA server is a commercial server on the public Internet. In this, the simplest case, public DNS servers will resolve the FQDN. The only requirement is that cOS Stream 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 a server request to pass from the validation request source (either the Clavister NetShield Firewall or a client) to the CA server and the reply to be received. If the request is going to pass through the Clavister NetShield Firewall, the appropriate rules in the main IP rule set need to be defined to allow this traffic through. The Service object used in the IP rules should be chosen to match the protocols that may be used for the request.

IP rules are not required if it is cOS Stream itself that is issuing the request to the CA server. Actions taken by cOS Stream are trusted by default. This is the case when cOS Stream must validate certificates in an LTE telecoms scenario and is a general rule that also applies to DNS resolution requests issued by cOS Stream.
If LDAP requests are going to be sent to a CA server then the server must be configured to accept anonymous LDAP requests. Microsoft documentation may refer to this as Anonymous LDAP Binding.

For example, the default setting for some Windows Active Directory servers is to reject anonymous LDAP requests so this must be changed.

cOS Stream always queries LDAP servers with anonymous requests and if the server is not configured to accept them, authentication will fail.

	CA servers with IPv4 or IPv6 addresses are Supported
	If the DNS resolution of a CA server name results in an IPv6 address instead of an IPv4 address then this is fully supported by cOS Stream. CRL lookup can be performed using either IPv4 or IPv6 addresses.

Placement of Private CA Servers

The simplest solution for placement of a private CA server is to have it on the unprotected side of the Clavister NetShield Firewall. This however, 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 Stream control access to it.

As explained previously, the FQDN address of the private CA server must be resolvable through public DNS servers for certificate validation requests coming from the public Internet. If the certificate queries are coming only from the Clavister NetShield 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 Stream so that these requests can be resolved and this is the case in the LTE telecoms scenario.

CA server access with LTE configuration is described further in the separate Clavister NetShield Firewall Use Case Guide.

Figure 16.1. Certificate Validation Components

Turning Off Certificate Validation

One of the ways to troubleshoot problems with CA server access can be done by turning off the requirement to validate certificates. By default, checking is always enabled.

Attempts to access CA servers by cOS Stream can be disabled by setting the CRLChecks option for a certificate object to Disabled (the default is Yes. For example:

System:/> cc CertificateStore ipsec
System:/CertificateStore/ipsec> set Certificate my_cert
			CRLChecks=Disabled

This means that checking against the CA server's revocation list (CRL) will be turned off and access to the server will not be attempted.

When switching off CRL checking, it may not be necessary to apply the CRLChecks=Disabled option to all certificates. This option follows the chain of certificate dependency. If it is applied to the root certificate of the chain then it is automatically applied to all dependent certificates.

Configuring LDAP Servers

If the FQDN in a certificate uses the LDAP protocol, then this can be specified in one of two ways:

With the prefix ldap:// - the URL of the LDAP server immediately follows the prefix.
With the prefix ldap:/// - the server URL is not specified and a default server is expected.

In the second case where the LDAP URL is not specified, the LDAP server to use is specified with the LDAPServer property of the certificate object. This property is set to a single LDAPServer object (a list of servers is not possible) which has already been defined in the configuration. The LDAPServer object specifies the IPv4 or IPv6 address of the server.

Example 16.1. Specifying an LDAP Server

This example creates an LDAPServer object called my_ldap_server which is then assigned to the Certificate object my_cert.

It is assumed that the IPv4 address of the LDAP server is 192.168.1.10. It is also assumed that the Certificate object my_cert already exists is located in the CertificateStore called ipsec.

Command-Line Interface

First, define the LDAPServer object:

System:/> add LDAPServer my_ldap_server IPAddress=192.168.1.10

Next, assign this server to the certificate:

System:/> cc CertificateStore ipsec
System:/CertificateStore/ipsec> set Certificate my_cert
			LDAPServer=my_ldap_server

CA Server Redundancy

It is possible to have redundancy of CA servers with any of the following methods:

The FQDN in the certificate can resolve to more than one IP address. This provides alternative servers to use if the first IP fails to return a response.
There can be more than one FQDN in the certificate. Again, this provides alternative servers if the first fails to respond. In this case, the protocols of the FQDNs are usually different with one being HTTP and the other being LDAP.

However, there can only be a single LDAP server explicitly specified in the LDAPServer property of a Certificate object.