- play_arrow Port Security
- play_arrow Port Security Overview
-
- play_arrow IPSec
- play_arrow Understanding IPsec and Security Associations
- play_arrow IPsec Configurations and Examples
- play_arrow Configuring IPsec Security Associations
- play_arrow Using Digital Certificates for IPsec
- play_arrow Additional IPsec Options
- play_arrow Configuring IPsec Dynamic Endpoints
- play_arrow Additional ES and AS PIC Configuration Examples
- Example: ES PIC Manual SA Configuration
- Example: AS PIC Manual SA Configuration
- Example: ES PIC IKE Dynamic SA Configuration
- Example: AS PIC IKE Dynamic SA Configuration
- Example: IKE Dynamic SA Between an AS PIC and an ES PIC Configuration
- Example: AS PIC IKE Dynamic SA with Digital Certificates Configuration
- Example: Dynamic Endpoint Tunneling Configuration
-
- play_arrow Trusted Platform Module
- play_arrow MACsec
- play_arrow Understanding MACsec
- play_arrow MACsec Examples
-
- play_arrow MAC Limiting and Move Limiting
- play_arrow MAC Limiting and Move Limiting Configurations and Examples
- Understanding MAC Limiting and MAC Move Limiting
- Understanding MAC Limiting on Layer 3 Routing Interfaces
- Understanding and Using Persistent MAC Learning
- Configuring MAC Limiting
- Example: Configuring MAC Limiting
- Verifying That MAC Limiting Is Working Correctly
- Override a MAC Limit Applied to All Interfaces
- Configuring MAC Move Limiting (ELS)
- Verifying That MAC Move Limiting Is Working Correctly
- Verifying That the Port Error Disable Setting Is Working Correctly
-
- play_arrow DHCP Protection
- play_arrow DHCPv4 and DHCPv6
- play_arrow DHCP Snooping
- Understanding DHCP Snooping (ELS)
- Understanding DHCP Snooping (non-ELS)
- Understanding DHCP Snooping Trust-All Configuration
- Enabling DHCP Snooping (non-ELS)
- Configuring Static DHCP IP Addresses
- Example: Protecting Against Address Spoofing and Layer 2 DoS Attacks
- Example: Protecting Against DHCP Snooping Database Attacks
- Example: Protecting Against ARP Spoofing Attacks
- Example: Prioritizing Snooped and Inspected Packet
- Configuring DHCP Security with Q-in-Q Tunneling in Service Provider Style
- play_arrow DHCP Option 82
- play_arrow Dynamic ARP Inspection (DAI)
-
- play_arrow IP Source Guard
- play_arrow Understanding IP Source Guard
- play_arrow IP Source Guard Examples
- Example: Configuring IP Source Guard on a Data VLAN That Shares an Interface with a Voice VLAN
- Example: Configuring IP Source Guard with Other EX Series Switch Features to Mitigate Address-Spoofing Attacks on Untrusted Access Interfaces
- Example: Configuring IP Source Guard and Dynamic ARP Inspection to Protect the Switch from IP Spoofing and ARP Spoofing
- Example: Configuring IPv6 Source Guard and Neighbor Discovery Inspection to Protect a Switch from IPv6 Address Spoofing
- Configuring IP Source Guard to Mitigate the Effects of Source IP Address Spoofing and Source MAC Address Spoofing
- Example: Configuring IP Source Guard and Dynamic ARP Inspection on a Specified Bridge Domain to Protect the Devices Against Attacks
- Example: Configuring IPv6 Source Guard and Neighbor Discovery Inspection to Protect a Switch from IPv6 Address Spoofing
-
- play_arrow IPv6 Access Security
- play_arrow Neighbor Discovery Protocol
- play_arrow SLAAC Snooping
- play_arrow Router Advertisement Guard
-
- play_arrow Control Plane Distributed Denial-of-Service (DDoS) Protection and Flow Detection
- play_arrow Control Plane DDoS Protection
- play_arrow Flow Detection and Culprit Flows
-
- play_arrow Unicast Forwarding
- play_arrow Unicast Reverse Path Forwarding
- play_arrow Unknown Unicast Forwarding
-
- play_arrow Storm Control
- play_arrow Malware Protection
- play_arrow Juniper Malware Removal Tool
-
- play_arrow Configuration Statements and Operational Commands
Public Key Cryptography
Understanding Public Key Cryptography on Switches
Cryptography describes the techniques related to the following aspects of information security:
Privacy or confidentiality
Integrity of data
Authentication
Nonrepudiation or nonrepudiation of origin—Nonrepudiation of origin means that signers cannot claim that they did not sign a message while claiming that their private key remains secret. In some nonrepudiation schemes used in digital signatures, a timestamp is attached to the digital signature, so that even if the private key is exposed, the signature remains valid. Public and private keys are described in the following text.
In practice, cryptographic methods protect the data transferred from one system to another over public networks by encrypting the data using an encryption key. Public key cryptography (PKC), which is used on Juniper Networks EX Series Ethernet Switches, uses a pair of encryption keys: a public key and a private key. The public and private keys are created simultaneously using the same encryption algorithm. The private key is held by a user secretly and the public key is published. Data encrypted with a public key can be decrypted only with the corresponding private key and vice versa. When you generate a public/private key pair, the switch automatically saves the key pair in a file in the certificate store, from which it is subsequently used in certificate request commands. The generated key pair is saved as certificate-id.priv.
The default RSA and DSA key size is 1024 bits. If you are using the Simple Certificate Enrollment Protocol (SCEP), Juniper Networks Junos operating system (Junos OS) supports RSA only.
Public Key Infrastructure (PKI) and Digital Certificates
Public key infrastructure (PKI) allows the distribution and use of the public keys in public key cryptography with security and integrity. PKI manages the public keys by using digital certificates. A digital certificate provides an electronic means of verifying the identity of an individual, an organization, or a directory service that can store digital certificates.
A PKI typically consists of a Registration Authority (RA) that verifies the identities of entities, authorizes their certificate requests, and generates unique asymmetric key pairs (unless the users’ certificate requests already contain public keys); and a Certificate Authority (CA) that issues corresponding digital certificates for the requesting entities. Optionally, you can use a Certificate Repository that stores and distributes certificates and a certificate revocation list (CRL) identifying the certificates that are no longer valid. Each entity possessing the authentic public key of a CA can verify the certificates issued by that CA.
Digital signatures exploit the public key cryptographic system as follows:
A sender digitally signs data by applying a cryptographic operation, involving its private key, on a digest of the data.
The resulting signature is attached to the data and sent to the receiver.
The receiver obtains the digital certificate of the sender, which provides the sender’s public key and confirmation of the link between its identity and the public key. The sender’s certificate is often attached to the signed data.
The receiver either trusts this certificate or attempts to verify it. The receiver verifies the signature on the data by using the public key contained in the certificate. This verification ensures the authenticity and integrity of the received data.
As an alternative to using a PKI, an entity can distribute its public key directly to all potential signature verifiers, so long as the key’s integrity is protected. The switch does it by using a self-signed certificate as a container for the public key and the corresponding entity’s identity.
See Also
Understanding Self-Signed Certificates on EX Series Switches
When you initialize a Juniper Networks EX Series Ethernet Switch with the factory default configuration, the switch generates a self-signed certificate, allowing secure access to the switch through the Secure Sockets Layer (SSL) protocol. Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) and XML Network Management over Secure Sockets Layer (XNM-SSL) are the two services that can make use of the self-signed certificates.
Self-signed certificates do not provide additional security as do those generated by Certificate Authorities (CAs). This is because a client cannot verify that the server he or she has connected to is the one advertised in the certificate.
The switches provide two methods for generating a self-signed certificate:
Automatic generation
In this case, the creator of the certificate is the switch. An automatically generated (also called “system-generated”) self-signed certificate is configured on the switch by default.
After the switch is initialized, it checks for the presence of an automatically generated self-signed certificate. If it does not find one, the switch generates one and saves it in the file system.
A self-signed certificate that is automatically generated by the switch is similar to an SSH host key. It is stored in the file system, not as part of the configuration. It persists when the switch is rebooted, and it is preserved when a
request system snapshotcommand is issued.The switch uses the following distinguished name for the automatically generated certificate:
“ CN=<device serial number>, CN=system generated, CN=self-signed”
If you delete the system-generated self-signed certificate on the switch, the switch generates a self-signed certificate automatically.
Manual generation
In this case, you create the self-signed certificate for the switch. At any time, you can use the CLI to generate a self-signed certificate. Manually generated self-signed certificates are stored in the file system, not as part of the configuration.
Self-signed certificates are valid for five years from the time they are generated. When the validity of an automatically generated self-signed certificate expires, you can delete it from the switch so that the switch generates a new self-signed certificate.
System-generated self-signed certificates and manually generated self-signed certificates can coexist on the switch.
Manually Generating Self-Signed Certificates on Switches (CLI Procedure)
EX Series switches allow you to generate custom self-signed certificates and store them in the file system. The certificate you generate manually can coexist with the automatically generated self-signed certificate on the switch. To enable secure access to the switch over SSL, you can use either the system-generated self-signed certificate or a certificate you have generated manually.
To generate self-signed certificates manually, you must complete the following tasks:
Generating a Public-Private Key Pair on Switches
A digital certificate has an associated cryptographic key pair that is used to sign the certificate digitally. The cryptographic key pair comprises a public key and a private key. When you generate a self-signed certificate, you must provide a public-private key pair that can be used to sign the self-signed certificate. Therefore, you must generate a public-private key pair before you can generate a self-signed certificate.
To generate a public-private key pair:
user@switch> request security pki generate-key-pair certificate-id certificate-id-name
Optionally, you can specify the encryption algorithm and the size of the encryption key. If you do not specify the encryption algorithm and encryption key size, default values are used. The default encryption algorithm is RSA, and the default encryption key size is 1024 bits.
After the public-private key pair is generated, the switch displays the following:
generated key pair certificate-id-name, key size 1024 bits
Generating Self-Signed Certificates on Switches
To generate the self-signed certificate manually, include the certificate ID name, the subject of the distinguished name (DN), the domain name, the IP address of the switch, and the e-mail address of the certificate holder:
user@switch> request security pki local-certificate generate-self-signed certificate-id certificate-id-name domain-name domain-name email email-address ip-address switch-ip-address subject subject-of-distinguished-name
The certificate you have generated is stored in the switch’s file system. The certificate ID you have specified while generating the certificate is a unique identifier that you can use to enable the HTTPS or XNM-SSL services.
To verify that the certificate was generated and loaded properly,
enter the show security pki local-certificate operational
command.
Deleting Self-Signed Certificates (CLI Procedure)
You can delete a self-signed certificate that is automatically or manually generated from the EX Series switch. When you delete the automatically generated self-signed certificate, the switch generates a new self-signed certificate and stores it in the file system.
To delete the automatically generated certificate and its associated key pair from the switch:
content_copy zoom_out_mapuser@switch> clear security pki local-certificate system-generated
To delete a manually generated certificate and its associated key pair from the switch:
content_copy zoom_out_mapuser@switch> clear security pki local-certificate certificate-id certificate-id-name
To delete all manually generated certificates and their associated key pairs from the switch:
content_copy zoom_out_mapuser@switch> clear security pki local-certificate all
Enabling HTTPS and XNM-SSL Services on Switches Using Self-Signed Certificates (CLI Procedure)
You can use the system-generated self-signed certificate or a manually generated self-signed certificate to enable Web management HTTPS and XNM-SSL services.
To enable HTTPS services using the automatically generated self-signed certificate:
content_copy zoom_out_map[edit] user@switch# set system services web-management https system-generated-certificate
To enable HTTPS services using a manually generated self-signed certificate:
content_copy zoom_out_map[edit] user@switch# set system services web-management https pki-local-certificate certificate-id-name
Note:The value of the certificate-id-name must match the name you specified when you generated the self-signed certificate manually.
To enable XNM-SSL services using a manually generated self-signed certificate:
content_copy zoom_out_map[edit] user@switch# set system services xnm-ssl local-certificate certificate-id-name
Note:The value of the certificate-id-name must match the name you specified when you generated the self-signed certificate manually.
