HP A 5120 Manual

							 
201 
                    2B 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            X509v3 CRL Distribution Points: 
            URI:http://4.4.4.133:447/myca.crl 
 
    Signature Algorithm: sha1WithRSAEncryption 
        836213A4 F2F74C1A 50F4100D B764D6CE 
        B30C0133 C4363F2F 73454D51 E9F95962 
        EDE9E590 E7458FA6 765A0D3F C4047BC2 
        9C391FF0 7383C4DF 9A0CCFA9 231428AF 
        987B029C C857AD96 E4C92441 9382E798 
        8FCC1E4A 3E598D81 96476875 E2F86C33 
        75B51661 B6556C5E 8F546E97 5197734B 
        C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C 
You  can  also  use  some  other display commands—display  pki  certificate ca domain and display  pki crl 
domain commands—to  view  detailed  information  about  the  CA  certificate  and  CRLs. For  more 
information about the commands, see the Security Command Reference. 
Requesting a certificate from a CA running Windows 2003 
Server  
 NOTE: 
The CA server runs the Windows 2003 server in this configuration example.  
Network requirements 
Configure PKI entity Switch to request a local certificate from the CA server. 
Figure 56 Request a certificate from a CA running Windows 2003 server 
 
 
Configuration procedure 
1. Configure the CA server 
 Install the certificate service suites 
From  the  start  menu,  select Control  Panel > Add  or  Remove  Programs,  and  then  select Add/Remove 
Windows Components > Certificate Services and click Next to begin the installation. 
 Install the SCEP add-on 
Because a  CA  server  running  the Windows 2003  server  does  not  support  SCEP  by  default,  you must 
install  the  SCEP  add-on  so  that  the  switch  can  register  and  obtain  its  certificate automatically.  After  the 
SCEP  add-on  installation  completes,  a  URL  is  displayed,  which  you must configure  on  the  switch  as  the 
URL of the server for certificate registration.    CA server
InternetHost
Switch
PKI entity         
						

							 
202 
 Modify the certificate service attributes 
From  the  start  menu,  select Control  Panel > Administrative  Tools > Certificate  Authority.  If  the  CA  server 
and  SCEP  add-on  have  been  installed  successfully,  there  should  be  two  certificates  issued  by  the  CA  to 
the  RA.  Right-click  on  the  CA  server  in  the  navigation  tree  and  select Properties > Policy  Module.  Click 
Properties and  then  select Follow  the  settings  in  the  certificate template,  if  applicable.  Otherwise, 
automatically issue the certificate. 
 Modify the Internet Information Services (IIS) attributes 
From  the  start  menu,  select Control  Panel > Administrative  Tools > Internet  Information  Services  (IIS) 
Manager and  then  select Web  Sites from  the  navigation  tree.  Right-click  on Default  Web  Site and  select 
Properties > Home  Directory.  Specify  the  path  for  certificate  service  in  the Local  path text  box.  In 
addition, specify an available port number as the TCP port number of the default website to avoid conflict 
with existing services. 
After  completing  the  configuration,  check  that  the  system  clock  of  the  switch  is  synchronous  to  that  of  the 
CA server, ensuring that the switch can request a certificate normally. 
2. Configure the switch 
 Configure the entity DN 
# Configure the entity name as aaa and the common name as switch. 
 system-view 
[Switch] pki entity aaa 
[Switch-pki-entity-aaa] common-name switch 
[Switch-pki-entity-aaa] quit 
 Configure the PKI domain 
# Create PKI domain torsa and enter its view. 
[Switch] pki domain torsa 
# Configure the name of the trusted CA as myca. 
[Switch-pki-domain-torsa] ca identifier myca 
# Configure the URL of the registration server in the format of http://host:port/ certsrv/mscep/mscep.dll, 
where host:port indicates the IP address and port number of the CA server. 
[Switch-pki-domain-torsa] certificate  request  url 
http://4.4.4.1:8080/certsrv/mscep/mscep.dll 
# Set the registration authority to RA. 
[Switch-pki-domain-torsa] certificate request from ra 
# Specify the entity for certificate request as aaa. 
[Switch-pki-domain-torsa] certificate request entity aaa 
 Generate a local key pair using RSA 
[Switch] public-key local create rsa 
The range of public key size is (512 ~ 2048). 
NOTES: If the key modulus is greater than 512, 
It will take a few minutes. 
Press CTRL+C to abort. 
Input the bits in the modulus [default = 1024]: 
Generating Keys... 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
++++++++++++++++++++++++++++++++++++++  
						

							 
203 
+++++++++++++++++++++++++++++++++++++++++++++++ 
+++++++++++++++++++++++ 
 
 Apply for certificates 
# Retrieve the CA certificate and save it locally. 
[Switch] pki retrieval-certificate ca domain torsa 
Retrieving CA/RA certificates. Please wait a while...... 
The trusted CAs finger print is: 
    MD5  fingerprint:766C D2C8 9E46 845B 4DCE 439C 1C1F 83AB 
    SHA1 fingerprint:97E5 DDED AB39 3141 75FB DB5C E7F8 D7D7 7C9B 97B4 
 
Is the finger print correct?(Y/N):y 
 
Saving CA/RA certificates chain, please wait a moment...... 
CA certificates retrieval success. 
# Request a local certificate manually. 
[Switch] pki request-certificate domain torsa challenge-word 
Certificate is being requested, please wait...... 
[Switch] 
Enrolling the local certificate,please wait a while...... 
Certificate request Successfully! 
Saving the local certificate to device...... 
Done! 
3. Verify your configuration 
# Use the following command to view information about the local certificate acquired. 
[Switch] display pki certificate local domain torsa 
Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            48FA0FD9 00000000 000C 
        Signature Algorithm: sha1WithRSAEncryption 
        Issuer: 
            CN=myca 
        Validity 
            Not Before: Feb 21 12:32:16 2011 GMT 
            Not After : Feb 21 12:42:16 2011 GMT 
        Subject: 
            CN=switch 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
            RSA Public Key: (1024 bit) 
                Modulus (1024 bit): 
                    00A6637A 8CDEA1AC B2E04A59 F7F6A9FE 
                    5AEE52AE 14A392E4 E0E5D458 0D341113 
                    0BF91E57 FA8C67AC 6CE8FEBB 5570178B  
						

							 
204 
                    10242FDD D3947F5E 2DA70BD9 1FAF07E5 
                    1D167CE1 FC20394F 476F5C08 C5067DF9 
                    CB4D05E6 55DC11B6 9F4C014D EA600306 
                    81D403CF 2D93BC5A 8AF3224D 1125E439 
                    78ECEFE1 7FA9AE7B 877B50B8 3280509F 
                    6B 
                Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            X509v3 Subject Key Identifier: 
            B68E4107 91D7C44C 7ABCE3BA 9BF385F8 A448F4E1 
            X509v3 Authority Key Identifier: 
            keyid:9D823258 EADFEFA2 4A663E75 F416B6F6 D41EE4FE 
 
            X509v3 CRL Distribution Points: 
            URI:http://l00192b/CertEnroll/CA%20server.crl 
            URI:file://\\l00192b\CertEnroll\CA server.crl 
 
            Authority Information Access: 
            CA Issuers - URI:http://l00192b/CertEnroll/l00192b_CA%20server.crt 
            CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt 
 
            1.3.6.1.4.1.311.20.2: 
                .0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e 
    Signature Algorithm: sha1WithRSAEncryption 
        81029589 7BFA1CBD 20023136 B068840B 
(Omitted) 
You can also use some other display commands—such as, display pki certificate ca domain command—
to  view more information  about  the  CA  certificate. For  more  information  about  the  command,  see the 
Security Command Reference. 
Configuring a certificate attribute-based access control policy 
Network requirements 
 The client accesses the remote HTTP Secure (HTTPS) server through the HTTPS protocol. 
 Configure SSL to ensure that only legal clients log in to the HTTPS server. 
 Create a certificate attribute-based access control policy to control access to the HTTPS server. 
Figure 57 Configure a certificate attribute-based access control policy 
 
    CA server
IP network
Host Switch
HTTPS clientHTTPS server     
						

							 
205 
Configuration procedure 
 
 NOTE: 
 For more information about SSL configuration, see the chapter “SSL configuration.“ 
 For more information about HTTPS configuration, see the Fundamentals Configuration Guide. 
 The PKI domain to be referenced by the SSL policy must be created in advance. For how to configure a PKI 
domain, see “Configure the PKI domain.”  
1. Configure the HTTPS server 
# Configure the SSL policy for the HTTPS server to use. 
 system-view 
[Switch] ssl server-policy myssl 
[Switch-ssl-server-policy-myssl] pki-domain 1 
[Switch-ssl-server-policy-myssl] client-verify enable 
[Switch-ssl-server-policy-myssl] quit 
2. Configure the certificate attribute group 
# Create certificate  attribute  group mygroup1 and add two  attribute  rules.  The  first  rule  defines  that  the 
DN of the subject name includes the string aabbcc, and the second rule defines that the IP address of the 
certificate issuer is 10.0.0.1.  
[Switch] pki certificate attribute-group mygroup1 
[Switch-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc 
[Switch-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ 10.0.0.1 
[Switch-pki-cert-attribute-group-mygroup1] quit 
# Create certificate  attribute  group mygroup2 and add two  attribute  rules.  The  first  rule  defines  that  the 
FQDN  of  the  alternative  subject  name  does  not  include  the  string of apple,  and  the  second  rule  defines 
that the DN of the certificate issuer name includes the string aabbcc.  
[Switch] pki certificate attribute-group mygroup2 
[Switch-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple 
[Switch-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc 
[Switch-pki-cert-attribute-group-mygroup2] quit 
3. Configure the certificate attribute-based access control policy 
# Create the certificate attribute-based access control policy of myacp and add two access control rules. 
[Switch] pki certificate access-control-policy myacp 
[Switch-pki-cert-acp-myacp] rule 1 deny mygroup1 
[Switch-pki-cert-acp-myacp] rule 2 permit mygroup2 
[Switch-pki-cert-acp-myacp] quit 
4. Apply the SSL server policy and certificate attribute-based access control policy to HTTPS service 
and enable HTTPS service.  
# Apply SSL server policy myssl to HTTPS service. 
[Switch] ip https ssl-server-policy myssl 
# Apply the certificate attribute-based access control policy of myacp to HTTPS service. 
[Switch] ip https certificate access-control-policy myacp 
# Enable HTTPS service.  
[Switch] ip https enable  
						

							 
206 
Troubleshooting PKI 
Failed to retrieve a CA certificate 
Symptom 
Failed to retrieve a CA certificate. 
Analysis 
Possible reasons include: 
 The network connection is not proper. For example, the network cable might be damaged or loose. 
 No trusted CA is specified. 
 The URL of the registration server for certificate request is not correct or not configured.  
 No authority is specified for certificate request. 
 The system clock of the device is not synchronized with that of the CA.  
Solution 
 Make sure that the network connection is physically proper. 
 Check that the required commands are configured properly. 
 Use the ping command to check that the RA server is reachable. 
 Specify the authority for certificate request. 
 Synchronize the system clock of the device with that of the CA.  
Failed to request a local certificate 
Symptom 
Failed to request a local certificate. 
Analysis 
Possible reasons include: 
 The network connection is not proper. For example, the network cable might be damaged or loose. 
 No CA certificate has been retrieved. 
 The current key pair has been bound to a certificate. 
 No trusted CA is specified. 
 The URL of the registration server for certificate request is not correct or not configured.  
 No authority is specified for certificate request. 
 Some required parameters of the entity DN are not configured.  
Solution 
 Make sure that the network connection is physically proper. 
 Retrieve a CA certificate. 
 Regenerate a key pair. 
 Specify a trusted CA.  
						

							 
207 
 Use the ping command to check that the RA server is reachable. 
 Specify the authority for certificate request. 
 Configure the required entity DN parameters.  
Failed to retrieve CRLs 
Symptom 
Failed to retrieve CRLs. 
Analysis 
Possible reasons include: 
 The network connection is not proper. For example, the network cable might be damaged or loose. 
 No CA certificate has been retrieved before you try to retrieve CRLs. 
 The IP address of LDAP server is not configured. 
 The CRL distribution URL is not configured. 
 The LDAP server version is wrong. 
Solution 
 Make sure that the network connection is physically proper. 
 Retrieve a CA certificate. 
 Specify the IP address of the LDAP server. 
 Specify the CRL distribution URL. 
 Re-configure the LDAP version. 
  
						

							 
208 
SSH2.0 configuration 
SSH2.0 overview 
Introduction to SSH2.0 
Secure Shell  (SSH)  offers  an  approach  to  logging  in to  a  remote  device securely. Using encryption  and 
strong  authentication, SSH protects devices  against  attacks  such  as  IP  spoofing  and  plain  text  password 
interception. 
The device can not only work as an SSH server to support connections with SSH clients, but also work as 
an SSH client to allow users to establish SSH connections with a remote device acting as the SSH server.   
 NOTE: 
 When acting as an SSH server, the device supports SSH2.0 and SSH1. When acting as an SSH client, the device 
supports SSH2.0 only. 
 Unless otherwise noted, SSH in this document refers to SSH2.0.  
How does SSH work 
To  establish  an  SSH  connection  and  communicate  with each  other  through  the  connection, an SSH  client 
and the SSH server go through the stages listed in Table 11. 
Table 11 Stages in session establishment and interaction between an SSH client and the server 
Stages Description 
Version negotiation SSH1 and SSH2.0 are supported. The two parties negotiate a version to 
use. 
Key and algorithm negotiation SSH supports multiple algorithms. The two parties negotiate algorithms 
for communication. 
Authentication The SSH server authenticates the client in response to the client’s 
authentication request. 
Session request After passing authentication, the client sends a session request to the 
server. 
Interaction After the server grants the request, the client and server start to 
communicate with each other. 
 
Version negotiation 
1. The server opens port 22 to listen to connection requests from clients. 
2. The client sends a TCP connection request to the server. 
3. After the TCP connection is established, the server sends a packet that carries a version information 
string to the client. The version information string is in the format SSH-.-. The primary and  
						

							 
209 
secondary protocol version numbers constitute the protocol version number. The software version 
number is used for debugging.  
4. Upon receiving the packet, the client resolves the packet and compares the server’s protocol 
version number with that of its own. If the server’s protocol version is lower and supportable, the 
client uses the protocol version of the server; otherwise, the client uses its own protocol version. In 
either case, the client sends a packet to the server to notify the server of the protocol version that it 
decides to use.  
5. The server compares the version number carried in the packet with that of its own. If the server 
supports the version, the negotiation succeeds and the server and the client proceed with key and 
algorithm negotiation. Otherwise, the negotiation fails, and the server breaks the TCP connection  
 NOTE: 
All the packets involved are transferred in plain text.  
Key and algorithm negotiation 
1. The server and the client send algorithm negotiation packets to each other, which include the 
supported public key algorithms list, encryption algorithms list, Message Authentication Code 
(MAC) algorithms list, and compression algorithms list.  
2. Based on the received algorithm negotiation packets, the server and the client figure out the 
algorithms to be used. If the negotiation of any type of algorithm fails, the algorithm negotiation 
fails and the server tears down the connection with the client. 
3. The server and the client use the DH key exchange algorithm and parameters such as the host key 
pair to generate the session key and session ID, and the client authenticates the identity of the 
server. 
Through the steps, the server and the client get the  same session key and  session ID. The session key will 
be  used  to  encrypt  and  decrypt  data  exchanged  between  the  server  and  client  later.  The  session  ID  will 
be  used  to  identify  the  session  established  between  the  server  and  client  and  will  be  used in  the 
authentication stage.   
 CAUTION: 
Before the negotiation, the server must have already generated a DSA or RSA key pair, which is used 
in generating the session key and by the client to authenticate the identity of the server. For more 
information about DSA and RSA key pairs, see the chapter “Public key configuration.”  
Authentication 
SSH provides password authentication and publickey authentication. 
 Password  authentication—The  server  uses AAA for  authentication  of  the  client.  During  password 
authentication,  the  client  encrypts its username  and  password,  encapsulates  them into  a  password 
authentication  request,  and sends the  request to  the  server.  Upon  receiving  the  request,  the  server 
decrypts  the username  and  password, checks the  validity  of  the  username  and  password locally  or 
by a remote AAA server, and then informs the client of the authentication result. 
 Publickey  authentication—The  server authenticates the client by the digital signature. During 
publickey  authentication,  the  client  sends  the server  a  publickey authentication  request that contains 
its username, public  key,  and  publickey algorithm information. The  server checks  whether the public 
key  is  valid.  If  the public  key is  invalid,  the  authentication  fails.  Otherwise,  the  server authenticates 
the client by the digital signature. Finally, the server sends a message to the client to inform it of the   
						

							 
210 
authentication result. The  device  supports using  the publickey algorithms RSA  and  DSA for digital 
signature. 
The following gives the steps of the authentication stage: 
1. The client sends the server an authentication request that includes the username, authentication 
method (password authentication or publickey authentication), and information related to the 
authentication method (for example, the password in the case of password authentication). 
2. The server authenticates the client. If the authentication fails, the server sends the client a message 
to inform the client of the failure and the methods available for re-authentication. 
3. The client selects a method from the list to initiate another authentication. 
4. The process repeats until the authentication succeeds, or the number of failed authentication 
attempts exceeds the maximum of authentication attempts and the session is torn down.  
 NOTE: 
In addition to password authentication and publickey authentication, SSH2.0 also provides the 
following authentication methods:  
 password-publickey—Performs both password authentication and publickey authentication if the client is using 
SSH2.0 and performs either if the client is running SSH1. 
 any—Performs either password authentication or publickey authentication.  
Session request 
After passing authentication, the client sends a session request to the server, and the server listens to and 
processes  the  request  from  the  client. After  successfully  processing  the  request,  the  server  sends  an 
SSH_SMSG_SUCCESS packet to the client and goes on to the interaction stage with the client. Otherwise, 
the server sends an SSH_SMSG_FAILURE packet to the client to indicate that the processing has failed or 
it cannot resolve the request. 
Interaction 
In this stage, the server and the client exchanges data in the following way: 
 The client encrypts and sends the command to be executed to the server. 
 The server decrypts and executes the command, and then encrypts and sends the result to the client. 
 The client decrypts and displays the result on the terminal.  
 NOTE: 
 In the interaction stage, you can execute commands from the client by pasting the commands in text format—the 
text must be within 2000 bytes. The commands should be in the same view. Otherwise, the server might not be 
able to perform the commands correctly.  
 If the command text exceeds 2000 bytes, you can execute the commands by saving the text as a configuration 
file, uploading the configuration file to the server through Secure FTP (SFTP), and then using the configuration file 
to restart the server.  
Configuring the device as an SSH server 
SSH server configuration task list 
Complete the following tasks to configure an SSH server: