BGP/BGP4+

Security Policy

BGP MD5 authentication

BGP uses TCP as its transport layer protocol and considers a TCP packet valid if the source IP address, destination IP address, source port number, destination port number, and TCP sequence number in the packet are correct. Most of the preceding parameters in a TCP packet can be obtained by attackers without much difficulty. To protect BGP from attacks, you can configure MD5 authentication over TCP between BGP peers.

The cleartext passwords configured on both ends must be the same. If the interval between the configuration completions of the two devices is greater than hold-time, the peer relationship is interrupted. Otherwise, the peer relationship is not interrupted.

To prevent an MD5 password configured for a BGP peer from being cracked, change the password periodically.

The MD5 algorithm is not recommended if high security is required.
Keychain authentication

A keychain consists of multiple authentication keys, each of which contains an ID and a password. Each key in a keychain has a lifecycle, and keys are dynamically selected based on the lifecycle of each key. After a keychain with the same rules is configured on the two ends of a BGP session, authentication keys are dynamically selected to enhance BGP attack defense.
TCP-AO authentication
The TCP authentication option (TCP-AO) is used to authenticate received and to-be sent packets during TCP session establishment and data exchange. It supports packet integrity check to prevent TCP replay attacks. TCP-AO authentication improves the security of the TCP connection between BGP peers and is applicable to the network that requires high security.
BGP GTSM

GTSM checks TTL values to defend against attacks. Attackers may simulate BGP messages and continuously send them to the router. After receiving these packets, the interface board on the router sends these messages directly to the control plane for BGP processing, without validating them, if they are destined for the device. The router becomes extremely busy, and CPU usage is high because the control plane of the router needs to process these unchecked messages.

GTSM protects the router by checking whether the TTL value within the IP packet header is in a pre-defined range to improve system security.
BGP whitelist

The application layer association module checks protocol packets sent to the CPU and sends protocol packets that match the whitelist at a high rate.
CP-CAR

For enabled services or protocols, a device can limit the rate at which packets are sent to the CPU, protecting the CPU from attacks and ensuring proper network operating.
Session-CAR
The function of whitelist session-CAR for BGP sets an independent CAR channel for each BGP session to ensure that the bandwidth of each BGP session is not preempted by other traffic (including traffic from other sessions of the same protocol and traffic from other protocols). When BGP messages suffer a traffic burst, you can adjust the default parameters of whitelist session-CAR for BGP if they do not meet service requirements. This ensures that BGP messages can be sent properly.
Route over-threshold control

In most cases, a BGP routing table contains a large number of routes. If a lot of routes are received from a peer, excessive system resources may be consumed. To prevent this issue, you can set the maximum number of routes that the local BGP device can accept from the peer.
Limit on the quantity of AS numbers in the AS_Path attribute

When a BGP device receives a route, it checks whether the quantity of AS numbers in the AS_Path attribute exceeds a specified threshold. If the quantity exceeds the threshold, the device discards the route. During route advertisement, the device also checks whether the quantity of AS numbers in the AS_Path attribute exceeds the threshold. If the quantity exceeds the threshold, the device does not advertise the route to prevent maliciously constructed error packets with an extra-long AS_Path list from attacking the router.
RPKI

Resource Public Key Infrastructure (RPKI) improves BGP/BGP4+ security by validating the origin ASs of BGP/BGP4+ routes.

RPKI is mainly applied to the networking where an RPKI server exists and the origin ASs of BGP/BGP4+ routes needs to be validated. In addition, you can apply the validation result to BGP/BGP4+ route selection to ensure that hosts in the local AS can securely communicate with hosts in other ASs.
BMP

The BGP/BGP4+ Monitoring Protocol (BMP) monitors BGP/BGP4+ running status, such as peer relationship establishment and termination and route updates.

Without BGP/BGP4+ Monitoring Protocol (BMP), manual query is required if you want to know about BGP/BGP4+ running status. To improve the network monitoring efficiency, you can configure BMP on a device to use a monitoring server on the network to monitor the BGP/BGP4+ running status.
BGP TLS authentication
The Transport Layer Security (TLS) protocol, as the SSL successor, ensures data integrity and privacy. SSL/TLS authentication can be configured on an SSL server so that BGP messages are encrypted to ensure data transmission security on the network.

Attack Methods

DoS attacks

Attackers can send various types of packets to attack devices. If the packets are multicast protocol packets or the destination IP address is the IP address of an interface (including the loopback interface) on the device, the device sends these packets to the CPU. These packets consume the CPU and system resources, causing DoS attacks. After a BGP session is created, the system sends a whitelist. The application layer association module checks the received protocol packets and sends protocol packets that match the whitelist at a high rate. The module sends protocol packets that do not match the whitelist at the default bandwidth and rate to prevent DoS attacks. In addition, CP-CAR applies to interfaces to limit the transmission rate of BGP packets, to protect the CPU from attacks, and to ensure proper network operations.
Injection of a large number of BGP routes

BGP runs on various models of devices, such as the IASs on an access network and NetEngine 8000 Fs. The number of BGP routes is determined by the CPU and memory of a device. If the number of BGP routes received by a device exceeds the capacity of the device, the device cannot run properly, and services cannot be provided properly because the memory of the device is exhausted. The maximum number of routes for a single peer can be set. If attackers inject a large number of routes and the quantity exceeds the value specified by the maximum number of routes for a single peer, the excess routes are discarded to prevent exhaustion of system resources.
Construction of error BGP messages

Attackers may construct various types of error packets, such as packets with extra-long AS_Paths, packets with incorrect packet headers, packets with incorrect lengths, and packets with invalid next hops. The attackers use these error packets to attack devices. BGP implements a policy "tolerant on input and strict on output". The device discards error packets without interrupting connections to peers to ensure uninterrupted services. For packets with extra-long AS_Paths, an AS_Path limit is set. During route reception or advertisement, if the device finds that the AS_Path exceeds the limit, it refuses to accept or advertise routes.

A BGP Update message contains various path attributes. If a local device receives Update messages containing malformed path attributes, the involved BGP sessions may flap. To resolve this issue and enhance reliability, run the peer path-attribute-treat command to configure a special mode in which the device processes specified path attributes in received BGP Update messages. Special modes indicate those that are not defined in a standard protocol.
Network packet attacks

It is easy for attackers to obtain the majority of parameters in the quintuple of a packet. To protect BGP from attacks, take the following measures:
- Use TCP MD5 authentication between BGP peers to reduce the possibility of being attacked.
- Configure keychain authentication for BGP sessions to enhance BGP anti-attack performance.
- Configure the GTSM function to check TTLs in messages to prevent attacks.

Procedure

Configure MD5 authentication.
An MD5 authentication password is configured for TCP connections, and TCP implements MD5 authentication of BGP. If authentication fails, no TCP connections can be established.
1. Run system-view
  The system view is displayed.
2. Run bgp as-number
  The BGP view is displayed.
3. Run peer { ipv4-address | group-name } password { cipher cipher-password | simple simple-password }
  An MD5 authentication password is set.
  
  An MD5 authentication password can be set in either ciphertext or cleartext:
  - cipher cipher-password indicates that a password is set using a ciphertext string.
  - simple simple-password indicates that a password is set using a cleartext string.
  - The password must be at least eight characters long and contains at least two of the following character types: uppercase letters, lowercase letters, digits, and special characters.
  - For security purposes, you are advised to specify the ciphertext mode and to change the password periodically. If this command is run in the BGP view, the configuration also takes effect in an extended BGP address family view because they use the same TCP connection. BGP MD5 authentication and BGP keychain authentication are mutually exclusive.
4. Run commit
  The configuration is committed.
Configure keychain authentication.
Configure keychain authentication on both ends of a BGP peer relationship. In addition, the configured keychains must use the same encryption algorithm and password so that TCP connections can be set up, and BGP messages can be exchanged properly.
1. Run system-view
  The system view is displayed.
2. Run bgp as-number
  The BGP view is displayed.
3. Run peer { ipv4-address | group-name } keychain keychain-name
  Keychain authentication is configured.
  
  To ensure the setup of a TCP connection and BGP exchange between on both ends of a BGP connection, configure keychain authentication specified for TCP-based applications and the same password and encryption algorithms on both ends.
  
  keychain-name specified in this command must exist; otherwise, the TCP connection cannot be established. For keychain configuration details, see the "Keychain Configuration" chapter in HUAWEI NetEngine 8000 F Series Configuration Guide - Security.
  - When this command is used in the BGP view, it is also applicable to the extended address family view because they use the same TCP connection.
  - BGP MD5 authentication and BGP keychain authentication are mutually exclusive.
4. Run commit
  The configuration is committed.
Configure TCP-AO authentication.
TCP-AO authentication must be configured on both BGP peers. A TCP-AO authentication password needs to be set for a TCP connection, and the authentication is performed by TCP. If authentication fails, no TCP connections can be established.
1. Run system-view
  The system view is displayed.
2. Run tcp ao tcpaoname
  A TCP-AO is created, and its view is displayed.
3. Run binding keychain kcName
  The TCP-AO is bound to a keychain.
  
  A keychain must have been created using the keychain command before you perform this step.
4. Run key-id keyId
  A key ID is created for the TCP-AO, and the TCP-AO key ID view is displayed.
5. Run send-id sndId receive-id rcvId
  The send-id and receive-id are configured for the Key ID.
6. Run quit
  Return to the upper-level view.
7. Run quit
  Return to the system view.
8. Run bgp as-number
  The BGP view is displayed.
9. Run peer ipv4-address as-number as-number
  The IP address of a peer and the number of the AS where the peer resides are specified.
10. Run peer peerIpv4Addr tcp-ao policy tcp-ao-name
  TCP-AO authentication is configured for the TCP connection to be set up between BGP peers.
  
  The value of the tcp-ao-name parameter must be set to the TCP-AO created in step 2.
  
  For the same peer, the authentication modes TCP-AO, MD5, and keychain are mutually exclusive.
11. Run commit
  The configuration is committed.
Configure the BGP GTSM function.
GTSM protects routers from attacks by checking whether the TTL in the header of an IP packet is in the pre-defined range.
1. Run system-view
  The system view is displayed.
2. Run bgp as-number
  The BGP view is displayed.
3. Run peer { group-name | ipv4-address } valid-ttl-hops [ hops ]
  The BGP GTSM is configured.
  
  The valid TTL range of detected packets is [255 – hops + 1, 255]. For example, for an EBGP direct route, the value of hops is 1. That is, the valid TTL value is 255.
  - After GTSM is configured in the BGP view, the configuration also takes effect in the MP-BGP VPNv4 address family view because BGP and MP-BGP VPNv4 share a TCP connection.
  - GTSM and EBGP-max-hop are mutually exclusive because they both affect the TTL values in sent BGP messages. Therefore, only one of them can be used for a peer or peer group.
  A BGP device that is enabled with GTSM checks the TTL values in all BGP packets on interface boards. As required by the actual networking, packets whose TTL values are not within the specified range are discarded. In scenarios where GTSM is not configured on a BGP device, the received BGP messages are forwarded if the BGP peer configuration exists. Otherwise, the received BGP messages are discarded. This prevents bogus BGP messages from consuming CPU resources.
4. Run commit
  The configuration is committed.
Set the default GTSM action.
Perform the following steps on a GTSM-enabled router:
1. Run system-view
  The system view is displayed.
2. Run gtsm default-action { drop | pass }
  The default action to be taken for packets that do not match the GTSM policy is set.
  
  If the default action is configured but no GTSM policy is configured, GTSM does not take effect.
  
  This command is supported only on the Admin-VS and cannot be configured in other VSs. This command takes effect on all VSs.
3. Run commit
  The configuration is committed.
Configure RPKI.
Enable RPKI and configure RPKI session parameters on a client.
1. Run system-view
  The system view is displayed.
2. Run rpki
  RPKI is started, and the RPKI view is displayed.
3. Run session ipv4-address
  An address of the RPKI server is specified for a TCP connection to be set up between the client and RPKI server.
4. Run tcp port port-number [ password md5 cipher-password | keychain keychain-name ]
  Parameters are configured for the TCP connection to be set up between the client and RPKI server.
  
  MD5 authentication is not recommended if high security is required.
  - The new password is at least eight characters long and contains at least two of the following types: upper-case letters, lower-case letters, digits, and special characters, except the question mark (?) and space.
  - For security purposes, you are advised to configure a password in ciphertext mode. To further improve device security, periodically change the password.
5. (Optional) Run timer { aging aging-time | refresh refresh-time }
  Timers are configured for the RPKI session between the client and the RPKI server.
  
  aging-time specifies the aging time of validation information, and refresh-time specifies the interval at which validation information is updated. You can configure the two timers to achieve the desired level of BGP security. If high BGP security is desired, configure a small value for each timer. Note that frequent validation information updates will lead to high bandwidth resource consumption.
6. (Optional) Run rpki-limit limit [ alert-only | idle-forever | idle-timeout times ]
  The maximum number of Route Origination Authorization (ROA) entries that the device is allowed to receive in a session is configured.
  
  In most cases, a large number of ROA entries exist on an RPKI server. If the device receives a large number of ROA entries from the RPKI server, excessive system resources will be consumed. To prevent this problem, run the rpki-limit command to configure the maximum number of ROA entries that the BGP device is allowed to receive in a session.
7. (Optional) Run connect-interface { interface-name | ipv4-source-address | interface-type interface-number | interface-type ipv4-source-address | interface-type interface-number ipv4-source-address }
  The source interface for sending RPKI packets is specified.
8. (Optional) Run ssl-policy policy-name
  An SSL policy to be bound to the TCP connection between the device and RPKI server is configured.
9. Run commit
  The configuration is committed.
  
  After RPKI session configurations are changed, run the reset rpki session command to reset the involved RPKI session for the new configurations to take effect.
Apply the BGP origin AS validation result to route selection.
1. Run system-view
  The system view is displayed.
2. Run bgp as-number
  The BGP view is displayed.
3. Run prefix origin-validation enable
  Origin AS validation of RPKI is enabled.
  
  After origin AS validation is enabled, the device matches the origin AS of each received route against the ROAs in the database and provides the validation result, which can be Valid, NotFound, or Invalid.
  
  To check ROA data of routes, including the origin ASs, run the display rpki table command. RPKI origin AS validation takes effect on the routes received from EBGP peers, not on the routes received from IBGP peers.
4. Run bestroute origin-as-validation [ allow-invalid ]
  The BGP origin AS validation result of RPKI is applied to route selection.
  
  BGP selects routes in the order of Valid, NotFound, and Invalid. If allow-invalid is not specified in the command, BGP ignores the routes with the validation result being Invalid during route selection.
5. Run peer { ipv4-address | group-name } advertise-ext-community
  The device is configured to advertise extended community attributes to a specified peer.
6. Run peer { ipv4-address | group-name } advertise origin-as-validation
  The BGP device is enabled to advertise the origin AS validation result of RPKI to the specified peer or peer group.
  
  The BGP origin AS validation result of RPKI can be advertised only to IBGP peers.
7. Run commit
  The configuration is committed.
Configure the device to perform ROA on the routes to be advertised to an EBGP peer to control BGP route advertisement.
1. Run system-view
  The system view is displayed.
2. Run bgp as-number
  The BGP view is displayed.
3. Run peer { peerIpv4Addr | peerGroupName } origin-validation export [ include-not-found [ external ] ]
  The local device is configured to perform ROA on the routes to be advertised to an EBGP peer.
  
  After the local device is configured to perform ROA on the routes to be advertised to an EBGP peer, the device compares the origin AS of a route with that of the matched route recorded in the database. The ROA result can be Valid (indicating that the origin AS is correct), NotFound (indicating no result), or Invalid (indicating that the origin AS is incorrect). By default, only the routes whose ROA result is Valid are advertised. To configure the device to advertise the routes with the ROA result being Valid or NotFound, specify the include-not-found keyword in the preceding command. To configure the device to advertise the routes with the ROA result being Valid or NotFound (if the routes with the result being NotFound were received from another AS), specify the include-not-found external keyword in the preceding command.
4. Run commit
  The configuration is committed.
Apply the BGP regional validation result to BGP route selection.
1. Run system-view
  The system view is displayed.
2. Run rpki
  RPKI is started, and the RPKI view is displayed.
3. Run region-validation
  Regional validation is enabled, and the regional validation view is displayed.
4. You can configure regions or regional confederation as required.
  - Create a region.
    1. Run region region-id
      A region is created.
    2. Run description description-text
      A description is configured for the region.
    3. Run as-number { asn } &<1-100>
      An AS number list is configured so that the AS numbers in it can be added to the region.
    4. Run quit
      Exit the RPKI region-validation-region view.
  - Create a regional confederation.
    1. Run region region-id
      A region is created.
    2. Run quit
      Exit the RPKI region-validation-region view.
    3. Run region-confederation region-confederation-id
      A regional confederation is created.
    4. Run description description-text
      A description is configured for the regional confederation.
    5. Run region { region-id } &<1-100>
      A region ID list is configured in the regional confederation so that regions in the list are added to the regional confederation.
    6. Run quit
      Exit the RPKI region-validation-confederation view.
5. Run bgp as-number
  The BGP view is displayed.
6. Run region-validation
  BGP regional validation is enabled.
  
  Or run region-validation confed-check strict
  
  Strict BGP regional validation is enabled.
7. Run bestroute region-validation [ allow-invalid ]
  The BGP regional validation result is applied to BGP route selection.
  
  If regional validation succeeds, the route is valid and can participate in route selection. If regional validation fails, the route is invalid and cannot participate in route selection. To allow the routes that fail regional validation to be valid and participate in route selection, configure the allow-invalid parameter in the command. The priority of such routes is reduced during route selection.
8. Run commit
  The configuration is committed.
Configure BMP.
1. Run system-view
  The system view is displayed.
2. Run bmp
  BMP is enabled, and the BMP view is displayed.
3. (Optional) Run statistics-timer time
  An interval at which the BMP device sends BGP/BGP4+ running statistics to a monitoring server is set.
  
  You can set the interval based on the actual requirements on BGP/BGP4+ stability. Usually, a shorter interval is set for a network with higher stability, but this consumes more bandwidth resources because the device sends BGP/BGP4+ running statistics more frequently.
4. Run bmp-session [ vpn-instance vrf-name ] { ipv4-address | ipv6-address } [ alias alias-name ]
  An IPv4/IPv6 BMP session address is specified for the TCP connection to be established between the device and the monitoring server.
  
  alias alias-name specifies an alias for a BMP session. If the BMP device needs to establish multiple TCP connections with the same monitoring server through different port numbers, specify one IPv4/IPv6 address and different session aliases (through the alias alias-name parameter) to differentiate each connection.
5. Configure the BMP device to send statistics about routes of specific types to the monitoring server.
  - Configure the BMP device to send the monitoring server the statistics about RIB-in routes (all received routes or only accepted routes) from BGP/BGP4+ peers in a specified address family.
    1. Run one of the following commands to enter the BMP-Monitor view:
      - monitor public: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of all BGP/BGP4+ peers in the public network address family to be monitored.
      - monitor all-vpn-instance: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of BGP/BGP4+ peers in all VPN instance address families to be monitored.
      - monitor peer: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of a specified BGP/BGP4+ peer in the public address family to be monitored.
      - monitor vpn-instance: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of all BGP/BGP4+ peers in a specified VPN instance address family to be monitored.
      - monitor vpn-instance peer: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of a specified BGP/BGP4+ peer in a specified VPN instance address family to be monitored.
    2. Run route-mode { ipv4-family unicast | ipv4-family labeled-unicast | ipv4-family vpnv4 | ipv6-family unicast | ipv6-family vpnv6 } adj-rib-in { pre-policy | post-policy }
      
      The BMP device is configured to send statistics about RIB-in routes of BGP/BGP4+ peers in a specified address family to the monitoring server.
      
      To configure the device to send statistics about all received routes, specify the pre-policy parameter in the command. To configure the device to send statistics about only accepted routes, specify the post-policy parameter in the command.
      
      If the pre-policy parameter is specified in the command, run the keep-all-routes command in the BGP view to save information about routes carried in BGP/BGP4+ Update messages that are received from all BGP/BGP4+ peers or peer groups after BGP/BGP4+ connections are established. Alternatively, run the peer keep-all-routes command to save information about routes carried in the BGP/BGP4+ Update messages that are received from a specified BGP/BGP4+ peer or peer group after the BGP connection is established.
  - Configure the BMP device to send statistics about RIB-out routes advertised to BGP/BGP4+ peers in a specified address family.
    Run one of the following commands to enter the BMP-Monitor view:
    - monitor public: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of all BGP/BGP4+ peers in the public network address family to be monitored.
    - monitor all-vpn-instance: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of BGP/BGP4+ peers in all VPN instance address families to be monitored.
    - monitor peer: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of a specified BGP/BGP4+ peer in the public address family to be monitored.
    - monitor vpn-instance: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of all BGP/BGP4+ peers in a specified VPN instance address family to be monitored.
    - monitor vpn-instance peer: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of a specified BGP/BGP4+ peer in a specified VPN instance address family to be monitored.
    Run route-mode { ipv4-family unicast | ipv4-family labeled-unicast | ipv4-family vpnv4 | ipv6-family unicast | ipv6-family vpnv6 } adj-rib-out { pre-policy | post-policy }
    
    The BMP device is configured to send statistics about RIB-out routes of BGP/BGP4+ peers in a specified address family to the monitoring server.
    
    To configure the device to send statistics about all routes, specify the pre-policy parameter in the command. To configure the device to send statistics about only the routes that match the export policy, specify the post-policy parameter in the command.
  - Configure the BMP device to send statistics about Local-RIB routes of BGP/BGP4+ peers in a specified address family.
    1. Run one of the following commands to enter the BMP-Monitor view:
      - monitor public: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of all BGP/BGP4+ peers in the public network address family to be monitored.
      - monitor vpn-instance: displays the BMP-Monitor view and allows the BGP/BGP4+ running status of all BGP/BGP4+ peers in a specified VPN instance address family to be monitored.
    2. Run route-mode { ipv4-family unicast | ipv4-family labeled-unicast | ipv4-family vpnv4 | ipv6-family unicast | ipv6-family vpnv6 } local-rib [ add-path ]
      The BMP device is configured to send statistics about Local-RIB routes of BGP/BGP4+ peers in a specified address family to the monitoring server.
6. Run quit
  Return to the BMP session view.
7. Run tcp connect port port-number [ password md5 cipher-password | keychain keychain-name ]
  Parameters for the TCP connection to be established between the device and the monitoring server are configured.
  
  Configuring MD5 is not recommended when high security is required.
8. (Optional) Run ssl-policy name policy-name
  An SSL policy is configured for BMP.
  
  Ensure that the specified SSL policy has been created using the ssl policy policy-name command in the system view.
9. (Optional) Run connect-interface { interface-type interface-number | ip-source-address | interface-type interface-number ip-source-address }
  The source interface is specified for sending BMP messages.
10. Run commit
  The configuration is committed.
  
  After configuring BMP session parameters, run the reset bmp session command to reset the BMP session for the new BMP session parameters to take effect.
Configure TLS authentication.
The Secure Sockets Layer (SSL) protocol protects data privacy based on the Internet. It allows a client and a server to communicate in a way designed to prevent eavesdropping. Specifically, to ensure data transmission security on a network, a BGP peer or peer group needs to be configured as an SSL client or as a server, and the SSL data encryption, identity authentication, and message integrity verification mechanisms need to be used.
1. Run system-view
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  The BGP view is displayed.
3. Run peer { group-name | ipv4-address } ssl-server certificate
  SSL/TLS certification is enabled on an SSL server.
4. Run peer { group-name | ipv4-address } ssl-policy name ssl-policy-name
  The SSL policy is applied to the SSL client or server.
5. Run peer { group-name | ipv4-address } ssl-policy role { client | server }
  A peer or peer group is configured as an SSL client or server.
6. Run commit
  The configuration is committed.
The peer as-number command has been run to create a peer.

SSL/TLS certification can be enabled only on servers. BGP MD5 authentication is mutually exclusive with BGP keychain authentication and only one of them can be configured for a BGP peer.

The configuration of a peer takes precedence over that of the peer group to which the peer belongs.

SSL/TLS certification takes effect only when SSL/TLS certification is enabled on the server (SSL/TLS certification is not required on the client), the SSL client and server are configured, SSL policies are applied to the client and server.