Practica ls


Practical 1: Firewall Implementation in Linux Firewall Configuration

Red Hat Enterprise Linux offers firewall protection for enhanced system security. A firewall exists between your computer and the network, and determines which resources on your computer remote users on the network can access. A properly configured firewall can greatly increase the security of your system.

Figure 4.7. Firewall Configuration


Practica ls

Next, you can decide whether to enable a firewall for your Red Hat Enterprise Linux system.

No firewall
No firewall provides complete access to your system and does no security checking. Security checking is the disabling of access to certain services. This should only be selected if you are running on a trusted network (not the Internet) or plan to do more firewall configuration later.

Enable firewall
If you choose Enable firewall, connections are not accepted by your system (other than the default settings) that are not explicitly defined by you. By default, only connections in response to outbound requests, such as DNS replies or DHCP requests, are allowed. If access to services running on this machine is needed, you can choose to allow specific services through the firewall. If you are connecting your system to the Internet, this is the safest option to choose. Next, select which services, if any, should be allowed to pass through the firewall. Enabling these options allow the specified services to pass through the firewall. Note, these services may not be installed on the system by default. Make sure you choose to enable any options that you may need.

Remote Login (SSH)
Secure Shell (SSH) is a suite of tools for logging in to and executing commands on a remote machine. If you plan to use SSH tools to access your machine through a firewall, enable this option. You need to have the openssh-server package installed in order to access your machine remotely, using SSH tools.

Web Server (HTTP, HTTPS)
The HTTP and HTTPS protocols are used by Apache (and by other Web servers) to serve webpages. If you plan on making your Web server publicly available, enable this option. This option is not required for viewing pages locally or for developing webpages. You must install the httpd package if you want to serve webpages.

File Transfer (FTP)
The FTP protocol is used to transfer files between machines on a network. If you plan on making your FTP server publicly available, enable this option. You must install the vsftpd package in order to publicly serve files.

Practica ls
Mail Server (SMTP)


If you want to allow incoming mail delivery through your firewall, so that remote hosts can connect directly to your machine to deliver mail, enable this option. You do not need to enable this if you collect your mail from your Internet Service Provider's server using POP3 or IMAP, or if you use a tool such as fetchmail. Note that an improperly configured SMTP server can allow remote machines to use your server to send spam.


By default, the Sendmail mail transport agent (MTA) does not accept network connections from any host other than the local computer. To configure Sendmail as a server for other clients, you must edit /etc/mail/ and change the DAEMON_OPTIONS line to also listen on network devices (or comment out this option entirely using the dnl comment delimiter). You must then regenerate /etc/mail/ by running the following command (as root): make -C /etc/mail You must have the sendmail-cf package installed for this to work. Additionally, you can now setup SELinux (Security Enhanced Linux) during your installation of Red Hat Enterprise Linux. SELinux allows you to provide granular permissions for all subjects (users, programs, and processes) and objects (files and devices). You can safely grant an application only the permissions it needs to do its function. The SELinux implementation in Red Hat Enterprise Linux is designed to improve the security of various server daemons while minimizing the impact on the day-to-day operations of your system. Three states are available for you to choose from during the installation process:

Disable — Select Disable if you do not want SELinux security controls enabled on this system.

The Disabled setting turns enforcing off and does not set up the machine for the use of a security policy.

Warn — Select Warn to be notified of any denials. The Warn state assigns labels to data and

programs, and logs them, but does not enforce any policies. The Warn state is a good starting place for users who eventually want a fully active SELinux policy, but who first want to see what effects the


Practica ls
policy would have on their general system operation. Note that users selecting the Warn state may notice some false positive and negative notifications.

Active — Select Active if you want SELinux to act in a fully active state. The Active state

enforces all policies, such as denying access to unauthorized users for certain files and programs, for additional system protection. Choose this state only if you are sure that your system can still properly function with SELinux fully enabled.

2. PKI implementation using PGP over a LAN
Designing a PKI
When you are designing your PKI, there are a few things you should consider:
• • •

How should your CA hierarchy look like (e.g. number of CAs and what their roles should be) How do you want to protect the private keys of the CAs Where should you create the publication points

Let us take a closer look at each of these design issues.

Designing a CA hierarchy that scales well
The numbers and levels of CAs you should implement basically depend on your security and availability requirements. You should try to organize your hierarchy according to your needs. There really isn’t a best practice guide in terms of how many CA levels you need, although it is extremely rare that anyone needs 4 or more levels; however there is a rule of thumb which we have listed in table 1 below that may be able to give you a good push in the right direction: CA Level Comments
• • • • • • •

Low security Lower security requirements for CA security Consists of a single root CA Small number of certificate requests Medium security Consists of an offline root and online subordinates The offline root CA is removed from the network

Practica ls
• • • • • •


The Issuing online CAs remains on the network Two or more CAs to issue each certificate template is recommended High security Consists of offline root and offline policy One or more online issuing subordinates Suits larger, geographically distributed, or high security organizations

Table 1: Number of CA levels needed As an additional note, you may recall from the first article, that there was something called a certificate policy which describes how and who will issue and distribute certificates to a subject (e.g. subjects being users, computers, devices etc.). If you ever believe that you may need more than one certificate policy, due to legal, geographical, organizational or certificate based usage, then you will definitely need a 3-level PKI hierarchy, since this requirement will require 2 or more policy CAs at level 2 (also known as the policy CAs). When you implement a PKI, you will always have to start with a root CA, no matter whether we deal with a 1level, 2-level or 3-level PKI hierarchy. Since the root CA always will be the root of trust, and most often implemented by using a self-issued certificate, it is essential that you protect the root CA's private key the best you possibly can. This should always be the case, no matter how many levels your PKI hierarchy consist of. If your PKI hierarchy consists of 2 levels or more, then your root CA requires a minimal amount of access, since it will only be the subordinate CAs that require access to the root CA. However, as the distance from the root CA increases (i.e. more levels are added), the security requirements decrease and the access increases with respect to the subordinate CAs. This will be an important factor when we have to start installing the CAs, which we will explain later in this article.

CA private keys
Before you start installing a CA, you should have a plan for what the size of the CA’s private key should be and also how it should be protected. Let us start by looking at the key size, which is very important for both security and compatibility reasons. Table 2 below lists the recommended

Key sizes:


Practica ls
Key size 4096 4096 2048

CA role Root CA Policy CA Issuing CA

Table 2: Recommended CA key size Normally, a key size of 4096 would be recommended for security reasons, especially for the root CA. However this may create all sorts of incompatibility problems with for example Cisco based network products (depending on what version of Cisco IOS is being used). This is due to the fact that many 3rd party products have problems handling key sizes larger than 2048. And since network equipment can be integrated in solutions such as 802.1x for validation and compliance, key size will matter. So make absolutely sure that you know what equipment will be used and what limitations there may be with respect to certificate handling, before you start your PKI implementation. Once you have defined the CA key size you want to use, it is time to look at how the CA private key should be protected. Protecting the CA private key By default, the CA uses Microsoft’s strong Cryptographic Service Provider (CSP) and protects its private key with the help of the built-in Data Protection API (DPAPI). This poses a problem, since all members of the local administrators group have access to the CA’s private key and any member of this group can export the CA’s private key and thereby create a new fake CA that can issue fake certificates. Other security challenges exist such as buffer overrun attacks from malicious software. So what should you do? Well the best answer is “it depends”. You will have to balance your security requirements with the costs and usability associated with the protection of the CA’s private key and it is often the CA hierarchy which dictates your options. In table 3 below, we have listed some of the most common ways to protect a CA’s private key. We will leave it up to you to work out a risk assessment in terms of how you best protect the private key of your CAs. Just remember that this is probably the most important component to protect with respect to your PKI. Protection method Local Certificate Store Pros (+)

Cons (-) to implement


Low security

Practica ls
• • • • •


Built-in CSP is only FIPS 140-1 compliant Low physical security,




Low cost Fairly easy to implement Low cost FIPS 140-2 compliant

(Smart Card or USB Token)

because smart card or token can be easily lost or stolen

Requires physical presence when Certificate Services is started

Requires special CSP that is both FIPS and 140-2 supports Certificate compliant Microsoft Services

Encrypted Virtual machines

• • • •

Easy to implement Low cost Not hardware dependant FIPS 140-2 compliant

• •

Medium security Vulnerable to analog

attacks, because hard drive or DVD containing virtual machine can be easily lost or stolen Hardware (HSM) Security Module
• • •

Very high security FIPS 140-2 Level 2 and 3 compliant Can be either PCI or LAN based

High cost (depending on configuration)




default planning

Can often be used as SSL

accelerators as well Table 3: Some of the most common ways to protect a CA’s private key In addition to the recommendations listed in table 3, you also want to increase the security of the CAs by making sure that all CAs, except for the issuing CAs are kept offline. By this we mean that they should at least be off the network and only connected to the network whenever the CRL and issued certificates for all CAs in your entire


Practica ls

PKI needs renewal. Mostly, the root and policy CAs are turned off entirely, but again, this should depend on how well your physical security is and how the CAs' private keys are protected as well as how reliable your hardware is.

Where to create the publication points
The last area we will focus on before we start the PKI implementation is the publishing location for Certificate Revocation Lists (CRL) and the CAs' public keys. This is known as the Certificate Distribution Points (CDP). There are different protocols which we can use to define the CDP and they are:
• • • •

HTTP LDAP (which in the Microsoft world normally means Active Directory) FTP File share (SMB)

In figure 1 below, we have illustrated where to publish the CRL and CA public keys along with the recommended protocol order for the most common protocols.

Figure 1: Recommended CDP protocol order As you can see, the recommended primary protocol should be HTTP and there is a good reason for this. HTTP is recommended because it is the best protocol for both internal and external publication points. HTTP is perfect if

Practica ls


you need to issue certificates for both internal and external users at the same time. Especially external usage is important to consider, since you would want to make sure that certificates used for VPN, NAQ or Wi-Fi access are checked for revocation, before the users are allowed access to your internal network. It is also important to note that if a CDP is not available for a given protocol, then it will time-out (usually after 30 seconds) and move on to the next protocol on the list. So by having the correct configuration from the beginning, you are delivering a great user experience, since the CRL can be checked from internal and external locations without the time-out issues and without compromising your network security setup. However, if you for one reason or another should choose the default protocol which is LDAP, then there is nothing wrong with this, especially if your PKI is only going to be used for internal purposes. Just beware that if you are using an Active Directory integrated PKI and you issue certificates to external users, then it will require that they be able to perform LDAP queries to your Active Directory (assuming you use Active Directory as a CDP LDAP repository). You should however also make sure that you have a redundant web server setup, using a DNS round-robin setup if your preferred protocol is HTTP. If you want to use LDAP, then you already have a redundant setup if you have two or more domain controllers in your domain.

Installing the PKI
Based on some of the design issues from our previous article, it is time to start the installation of your PKI. Since this is a quick guide, we will cover a few things along the way, even though they actually belong to the design stage. For the rest of this article, we will show you how to install a 2-level hierarchy consisting of an offline root CA and an online issuing CA in the same PKI using best practice methods. However before we start the installation, let us get a few practical things in place. In figure 2, we have illustrated a best practice validity period for each CA at each level (based on a 3-level hierarchy for a complete overview). The advantage with this model is that it will ensure you always have a consistency for the issued certificates at each level. If you only want to deploy a 2-level hierarchy, simply remove the CA in level-3. The model will still apply.


Practica ls

Figure 2: A best practice validity period for each CA at each level The other thing you should prepare before we start the installation is a text file called CAPolicy.inf. This file is used to customize your configuration of Windows Certificates Services. In this file, you will find important things such as:
• • • •

The CDP statement Certificate renewal settings such as validity period and key size The links for the CDP and AIA paths How often the CRL should be published

Create the file using Notepad and save it to %windir%\capolicy.inf (e.g. C:\Windows\capolicy.inf). We have made this task a lot easier for you, by supplying the files in our step-by-step guides below. With these things in mind, it is time to get technical. Installing an offline root CA To install an offline root CA, you will have to complete the following:
• • • •

Prepare a CAPolicy.inf file Install Windows Certificate Services Publish the CRL list Run the post-Configuration script

Here is how it should be done:

Practica ls


1. Install a server with Windows Server 2003 Standard Edition incl. SP1 or newer and make sure that it runs as a stand-alone server (i.e. it should not be a member of any domain) 2. Make the necessary parameter replacements in the CAPOlicy.inf file below (highlighted with red)

Filename: CAPolicy.inf 3. Copy the CAPolicy.INF file to %windir%\capolicy.inf 4. Navigate to the Start Menu / Control Panel / Add or Remove Programs |click Add/Remove Windows Components 5. In Windows Components Wizard, you select Certificates Services and click Next 6. Notice what the dialog box is displaying. You should not rename the computer once the Windows Certificate Services are installed. Click Yes


Practica ls

Figure 3 7. In the CA Type field, you click Stand-alone root CA, and put a checkmark at “Use custom settings to generate Note: It is normal that the Enterprise root CA and Enterprise subordinate CA options cannot be selected, since this server is not member of a domain the key pair and CA certificate” check box and click Next

Figure 4 8. Select the CSP you want to use for your offline root CA. For simplicity, we’ve selected the Microsoft Strong Cryptographic Provider v1.0, however you can also select another CSP if you, for example,

Practica ls


installed a Hardware Security Module (HSM) and connected the server to the HSM solution, before you started the CA installation procedure. Select the default hash algorithm SHA-1 Set the key length to 4096 Make sure that both the “Allow this CSP to interact with the desktop” and “Use an existing key” options are not checked. Click Next

Figure 5 9. Enter a common name for your root CA, configure the Distinguished name suffix (O=domain, C=local) and set the validity period to 20 years, then click Next


Practica ls

Figure 6 10.Accept the default suggestion for the certificate database and log files (or change it at will) and click Next

Practica ls


Figure 7 11.Since this is an offline root CA, there is no need to install IIS (Internet Information Services) and thus the reason why this dialog is displayed. Click OK

Figure 8 12.Click Finish


Practica ls

Figure 9 13.Click Start / Programs / Administrative Tools / Certificate Authority 14.Expand your CA server pane and right-click Revoked Certificates. Click All tasks / Publish

Practica ls


Figure 10 15.Select New CRL and click OK 16.Copy %windir%\system32\certsrv\certenroll\*.crt and *.crl to a USB key. You will need these files for the next subordinate CA that will be installed 17.You should also copy these files to the CDP HTTP location as indicated in the caconfig.inf file listed earlier. 18. Make the necessary parameter replacements in the file below (highlighted in red) and run the file from a command prompt


Practica ls

Practica ls
You are done installing the root CA.


We mentioned earlier that there are good security reasons to keep the root and policy CAs offline, which includes turning them off. Only the issuing CAs should be kept online. Because the root and policy CAs are kept offline, they should not be a member of a domain. Installing an online issuing enterprise CA To install an online issuing Enterprise CA, you will have to complete the following:
• • • • • • • •

Prepare a CAPolicy.inf file Install IIS (Internet Information Services) Install Windows Certificate Services Submit the sub CA certificate request to the parent CA Issue the sub CA certificate Install the sub CA certificate at the enterprise subordinate CA Run the post-Configuration script Publish the CRL list

Here is how you do it: 1. Install a server with Windows Server 2003 Enterprise Edition incl. SP1 or newer and make sure it is a member of a domain 2. Make sure that IIS (internet Information Services) has been installed. There is a note to this however. If you really want to do this right, then omit the IIS part. The only caveat doing so, is that you definitely need to know your PKI before you omit the IIS component. The advantage is a more simple setup, and one attack vector less. 3. Make the necessary parameter replacements in the CAPOlicy.inf file below (highlighted with red)


Practica ls

Filename: CAPolicy.inf 4. Copy the CAPolicy.INF file to %windir%\capolicy.inf 5. Navigate to the Start Menu / Control Panel / Add or Remove Programs / click Add/Remove Windows Components 6. In Windows Components Wizard, you select Certificates Services and click Next

Figure 11

Practica ls


7. Notice what the dialog box is displaying. You should not rename the computer once the Windows Certificate Services are installed. Click Yes 8. In the CA Type field, you click Enterprise subordinate CA and put a checkmark at “Use custom settings to generate the key pair and CA certificate” check box and click Next

Figure 12 9. Select the CSP you want to use for your issuing CA. For simplicity, we have selected the Microsoft Strong Cryptographic Provider v1.0, however you could also have selected another CSP if you, for example, installed a Hardware Security Module (HSM) and connected the server to the HSM solution, before you started the CA installation procedure. Select the default hash algorithm SHA-1 Set the key length to 2048 Make sure that both the “Allow this CSP to interact with the desktop” and “Use an existing key” options are not checked. Click Next


Practica ls

Figure 13 10.Enter a common name for your issuing CA and set the validity period to 5 years, then click Next

Practica ls


Figure 14 11.Accept the default suggestion for the certificate database and log files (or change at will) and click Next 12.A CA Certificate Request window is displayed. Select Save the request to a file and enter a path and a filename (the wizard will automatically add a .req extension to the filename). Copy the file to a USB key for later use. Click Next. We will be using this request file later on in this quick guide


Practica ls

Figure 15 13.Some certificate IIS application components will be added. Click Yes

Figure 16 14.(Optional) If you have not enabled ASP support in IIS, then the following dialog box is display. Click Yes

Figure 17

Practica ls


15. You are not quite done yet. As indicated in the dialog box, then you will need to generate a private key for your new issuing CA.

Figure 18 Click OK and continue. 16.Click Finish


Practica ls

Figure 19 17. Before you continue, you should publish the certificate and revocation list for your root CA to Active Directory. This is easily done by doing the following: a. Copy both the *.crt and *.crl files generated during the installation of the root CA to the %systemroot %\system32\certsrv\certenroll folder on the issuing CA server. b. Run the script below from a command line prompt in the same folder on your issuing CA. You have to run the script as a user who is a member of the Cert Publishers Group in Active Directory (normally someone with domain admin rights).

Practica ls


The script will automatically process the entire filename and complete the needed commands. 18. Make sure you have the certificate request file generated in Step 12. Log on to the root CA server 19.From the root CA server you click Start / Programs / Administrative Tools / Certificate Authority 20.Expand your CA server pane and right-click the server name. Click All tasks / Submit new request…

Figure 20 21.Locate the request file generated in Step 12 and click OK 22.In the left pane, click Pending Requests. Locate the certificate request in the right pane / Right-click the certificate request and select All Tasks / Issue 23.Next we need to export the certificate. In the left pane you click Issued Certificates. In the right pane you right-click the certificate and click Open


Practica ls

Figure 21 24.Click the details tab and click Copy to file…

Practica ls


Figure 22 25.The Certificate Export Wizard is displayed. Click Next


Practica ls

Figure 23 26.Select ”Cryptographic Message Syntax Standard ….” and”Include all certificates in the certification path if possible”. Click Next

Practica ls


Figure 24 27.Save the certificate to the same USB key used in Step 12. Click Next


Practica ls

Figure 25 28.Click Finish and the click OK 29. Now you go back to issuing the CA and click Start / Programs / Administrative Tools / Certificate Authority 30.Expand the CA server pane and right-click the server name. Click All tasks / Install CA certificate…

Practica ls


Figure 26 31.Locate the certificate you issued in Step 27 and click OK 32.Expand your CA server pane and right-click the server name. Click Start service


Practica ls

Figure 27 33.Copy %windir%\system32\certsrv\certenroll\*.crt and *.crl to a USB key. You will need to copy these files to your web servers that are being used as Certificate Distribution Points (CDP) using the HTTP protocol. This is the HTTP based CDP URL you defined in the issuing CAs caconfig.inf earlier. Note: This task should be scheduled and run automatically 34. Make the necessary parameter replacements in the file below (highlighted in red) and run the file from a command prompt

Practica ls



Practica ls

35. Expand your CA server pane and right-click Revoked Certificates. Click All tasks / Publish

Figure 28 36.Select New CRL and click OK 37. And finally, you are done. Conclusion In this article, we have given you some quick guidelines and best practice advice on how to best implement a PKI consisting of a combination of both offline standalone CAs and enterprise based online issuing CAs. You should know that the script used for publishing the root CAs certificate and CRL file to the local store of the issuing CA and Active Directory needs modifications if you are using a 3-level hierarchy. This is because the policy CA also needs to be published to the local certificate store of our enterprise based issuing CA and also needs to be published to Active Directory. To a certain extent you may find this third article a bit cumbersome, especially during the implementation of an online issuing CA. But once you try it, you find out that it is really not that difficult to implement a full blown PKI that is both scalable and secure. In our last article in this PKI quick guide series, we will show you how to verify our installation as well as maintain and troubleshoot a PKI using a few simple steps.

Practica ls
Why you need a PKI


Some years back, everybody was talking about the year 2000 as the year of the PKI. Many believed that the mainstream market was finally ready to take advantage of all the goodies a PKI could offer. However as you probably guessed, certificates and PKIs never really took off. It simply wasn’t sexy enough for management to digest and the technical staff (who at the time where the only ones that could see the value in a PKI) was not very good at selling the business case to management. However as time has progressed, PKI has once again become one of the hottest topics in both large and medium size businesses, although this time there is a much less ambitious and more realistic approach to certificate usage and PKIs among IT administrators and business decision makers. The shift in the security landscape, where security and improvements in Internet and mobile communication technologies have become a business enabler for many companies, means that certificates and PKIs are more ready for the mainstream business market now, than it has ever been. So what’s the big deal with a PKI you may ask and why should you care? Well basically it all comes down to certificate management. You see, certificates are everywhere you look today and often they’re used without you ever worrying about their existence. Some of the most common scenarios where certificates are used are (in no particular order):
• • • • • • • • •

Disk and file encryption (certificates are used to protect the symmetric crypto key) Multifactor authentication such as smart cards IPSec Digital signature RADIUS and 802.1x authentication Wireless networks NAP (Network Access Control) and NAQ (Network Access Quarantine) for compliance Code and driver signing SSL/TLS for protecting HTTP based traffic

As you can see, certificates are used in many places, and its main purpose is added security to your IT infrastructure/solutions. But if you also look at our list above, then you can probably imagine that this also means that you may have to administer a lot of certificates, depending on what features you want to take advantage of in your infrastructure and how you decide to implement them. This is where a PKI can be of help. A PKI is simply a way to centrally administer the issuing, renewing and revocation of certificates and build your own path of trust. The certificates and the PKI we will cover in this article series are X.509 v3 based, which means that we can do some pretty nifty stuff with the certificate usage, which we’ll take a closer look at in part 2 of this article series.


Practica ls

Before we move on, I would like to make a disclaimer in terms of what we will cover in this article series. The intentions of this article series is to give you a quick overview on the most important areas, so that you, with very little effort, can get a PKI foundation up-and-running in no time, and which is both scalable and manageable. However building a PKI can be a big project and if you’re a very security conscious IT administrator where things such as role delegation and FIPS-140 compliance is important to you, then you may want to take a closer look at the links we have provided at the end of this article. With these things in mind, let’s get straight to the point and get started with the planning phase.

Planning a PKI
OK, I admit that by introducing a planning phase in our first article, we aren’t exactly being technical right away which you may have hoped for. But nonetheless, the planning part is very important and we’ll show you how to get the planning done with the least amount of effort, by showing you what areas you should focus on. The most common mistake companies makes when they install Microsoft Certificate Services (and thereby establish a PKI) is that they ignore the planning part, and thus end up spending a lot more both in terms of resources and money once they realize that they may have overlooked some important issues when they went into the Add/Remove Windows Components menu on their Windows 2000 or Windows 2003 based server and put a checkmark in front of the Certificate Services components.

The areas you should consider during the planning of your future PKI are:
• • •

Check if your security policy is updated and ready for a PKI Create one or more certificate policies Create a certificate practice statement

Let’s take a closer look into each of the above areas

Check if your security policy is updated and ready for a PKI
Brian Komar who is the author of the excellent book “Microsoft Windows Server 2003 PKI and Certificate Security” (see link at the end of this article) and who has written several Microsoft whitepapers and given sessions on various Microsoft PKI subjects, often states that “A PKI enforces your organization’s security policies” which in my opinion pretty much says it all. Make sure that you have a security policy in your company that addresses your company’s business and IT strategy. Then align this strategy with the applications and

Practica ls


security services that will depend on certificates. Since a security policy needs to be approved by management or even the board members (after all, these people are responsible for your company’s business strategy), you’ll basically have a green light to move on with your PKI implementation. Should you be unfortunate enough, in that your company doesn’t have a corporate security policy, then consider looking at the following URL’s for inspiration and samples on various security policies including various corporate security policy samples based on the ISO 17799 standard.

Create one or more Certificate Policies
I admit it. Policies are not the most exciting stuff in the world, but nonetheless, they’re still very important. And if you want to avoid all the legal issues with respect to your PKI, you better consider having a Certificate Policy (CP) in place. The certificate policy describes how and who will issue and distribute certificates to a subject (i.e. subjects being users, computers, devices etc.). This can be a daunting task even though it’s very important, but don’t worry. Just follow the steps below and you’ll be well on your way to creating your certificate policy for your PKI. 1. Glance through the RFC 3647 which you can find. 2. Then take a look at how a great certificate policy should look like, although this policy is probably more detailed than what you may need.

Create a Certificate Practice Statement
We’re almost done with the planning part, but we still need to create a Certificate Practice Statement (CPS). The CPS is very similar to the Certificate Policy, except that it focuses on the security of a Certificate Authority (CA) during operations and the management of the certificates issued by the CA. A CPS is usually much shorter than the Security Policy and contains information on who’s liable in case the certificate is unable to adequately protect whatever it is supposed to protect. An example could be a secure SSL/TLS connection, when a customer is entering their credit card number. Other areas that (as a minimum) should be included in a CPS are how validation, renewal and revocation are handled by the CA responsible for issuing the certificates. You can look at a CPS as an agreement between the user of the certificate and the company which is responsible for the issuing CA. And as you may have guessed, we also have some great samples for a CPS, which may seem familiar to you. 1. Just like with the Certificate Policy earlier, you can glance through the RFC 3647 for CPS info as well, which you can find


Practica ls

2. And for inspiration, take a look at VeriSign’s CDP 3. Unlike the Certificate Policy, a CPS should always be made publically available so that a user of the certificates always has access to the CPS. In every certificate your CA issues, there should be a link that points to the location where the CPS is published. We’ll take a closer look at it in the last two articles.

How PGP works
PGP combines some of the best features of both conventional and public key cryptography. PGP is a hybrid cryptosystem. When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis. (Files that are too short to compress or which don't compress well aren't compressed.) PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.

How PGP encryption works
Decryption works in the reverse. The recipient's copy of PGP uses his or her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally-encrypted ciphertext.

How PGP decryption works
The combination of the two encryption methods combines the convenience of public key encryption with the speed of conventional encryption. Conventional encryption is about 1, 000 times faster than public key encryption. Public key encryption in turn provides a solution to key distribution and data transmission issues. Used together, performance and key distribution are improved without any sacrifice in security.

Practica ls 3. Setting up & configuring Router
Router Configuration Management


Cisco IOS releases 12.3 and 12.4 include fundamental router configuration management tools that the network engineers have been sorely missing for the last 20 years. The configuration management tools include the following features:

Configuration change notification and logging
The Configuration Change Notification feature allows you to monitor changes to router configuration without deploying AAA exec command authentication and accounting (only available with TACACS+ servers). After you configure it, all the configuration commands entered on the router are stored in a circular buffer (you can even specify its length) and optionally sent to a syslog server.

Contextual configuration difference
If you don’t log the router configuration commands on an external syslog server, one of the first questions you’d ask when being presented with a malfunctioning router would be “What were the recent configuration changes on this box?” The Contextual Configuration Difference feature is supposed to answer this question as long as you have a copy of a complete working configuration file. Startup configuration is usually a good starting point or you could use the Router Configuration Archive feature to generate snapshots of the router configuration. The Contextual Configuration Difference feature is not perfect; there are a few IOS configuration constructs (for example, policy maps) which it cannot process properly.

Router configuration archive
Router configuration archive functionality was introduced in IOS releases 12.3T and 12.4. It is a simple, yet powerful concept: every time the router operator requests it (or periodically, if so configured), the router stores its current configuration on an external storage. The external file names can include router name, configuration dateand-time, as well as a configuration version number. Due to the tight integration with the IOS file system, you can store archived configurations using any file transfer protocol your IOS release supports (FTP, RCP, TFTP, HTTP, HTTPS or SCP), or on Class C flash systems, internal drives, or USB drives.

Configuration rollback


Practica ls

The Configuration Rollback feature allows you to replace a running configuration with another configuration previously taken from the same router; an operation that would usually require a router reload. It uses the Contextual configuration difference feature to identify changes between the router configurations and applies to changes trying to bring the running configuration as close to the desired one as possible. As the Contextual configuration difference is not perfect, the Configuration rollback feature performs several retries and reports the trouble spots if it fails to synchronize the configurations in five retries.

Configuration replace
The Configuration rollback feature can be used to replace the running configuration with any configuration of your choice, but it lacks an important safeguard: if the new configuration breaks your connectivity with the router, there’s no way to revert back to the working configuration. The Configuration replace feature adds the needed safety measures: it archives the current configuration, uses the Configuration rollback feature to replace it with the target configuration and tries to revert back to the archived configuration if the change is not confirmed within the specified time interval.

Basic Router Configuration using SDM
This document describes how to use the Cisco Security Device Manager (SDM) in order to set the basic configuration of the router. This includes the configuration of the IP address, default routing, static and dynamic routing , static and dynamic NATing, hostname, banner, secret password, user accounts, and so forth. Cisco SDM allows you to configure your router in all kinds of network environments that includes small office home office (SOHO), branch office (BO), regional office, and central site or Enterprise headquarters using an easy-to-use web-based management interface. 1.1. Requirements This document assumes that the Cisco router is fully operational and configured to allow the Cisco SDM to make configuration changes. Note: Refer to Allowing HTTPS Access for SDM in order to allow the router to be configured by the SDM.

Components Used
The information in this document is based on these software and hardware versions:
• •

Cisco 3640 Router with Cisco IOS® Software Release 12.4(8) Cisco Security Device Manager (SDM) Version 2.3.1

Practica ls


The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

In this section, you are presented with the information to configure the basic settings for router in a network. Note: Use the Command Lookup Tool ( registered customers only) to obtain more information on the commands used in this section.

Network Diagram
This document uses this network setup:

Note: The IP addressing schemes used in this configuration are not legally routable on the Internet. They are RFC 1918 addresses which have been used in a lab environment.

Interface Configuration
Complete these steps in order to configure the interfaces of a Cisco router.

1. Click Home in order to go to the SDM Home page.
The SDM Home page provides information such as hardware and software of the router, feature availability, and a configuration summary. The green circles show the features supported in this router and the red circles show the features not supported.


Practica ls

2. Choose Configure > Interfaces and Connections > Create Connection in order to configure the WAN
connection for the interface. As an example, for serial interface 2/0, choose the Serial option and click Create New Connection. Note: For other types of interfaces like Ethernet, choose the respective interface type and proceed by clicking the Create New Connection button.

Practica ls


3. Click Next in order to proceed once this interface appears.


Practica ls

4. Select Serial interface 2/0 (desired) from the Available Interfaces option and click Next.

5. Choose the encapsulation type for the serial interface and click Next.

Practica ls
6. Specify the static IP address with the corresponding subnet mask for the interface and click Next.


7. Configure the default routing with optional parameters such as the next hop IP address ( as
per network diagram) supplied by the ISP and click Next.

This window appears and shows the configuration summary configured by the user. Click Finish.


Practica ls

This window appears and shows the command delivery status to the router. Otherwise, it displays errors if the command delivery fails due to incompatible commands or unsupported features.

Practica ls


8. Choose Configure > Interfaces and Connections > Edit Interfaces/Connections in order to add/edit/delete
the various interfaces.

Highlight the interface with which you want to make changes and click Edit if you want to edit or change the interface configuration. Here you can change the existing static IP address.


Practica ls

NAT Configuration
Dynamic NAT Configuration Complete these steps in order to configure the dynamic NAT in a Cisco router.

1. Choose Configure > NAT > Basic NAT and click Launch the selected task in order to configure basic

2. Click Next.

Practica ls


3. Choose the interface that connects to the Internet or your ISP and select the IP address range to which Internet access is to be shared.


Practica ls

4. This window appears and shows the configuration summary configured by the user. Click Finish.

5. The Edit NAT Configuration window shows the configured dynamic NAT configuration with the
translated IP address overloaded (PATing). If you want to configure the dynamic NATing with address pool, click Address Pool.

Practica ls
6. Click Add.


Here informations such as the pool name and IP address range with netmask are provided. There can be times when most of the addresses in the pool have been assigned, and the IP address pool is nearly depleted. When this occurs, PAT can be used with a single IP address to satisfy additional requests for IP addresses. Check Port Address Translation (PAT) if you want the router to use PAT when the address pool is close to depletion.

7. Click Add.


Practica ls

8. Click Edit.

9. Choose Address Pool in the Type field, provide the name to the Address Pool as pool1 and click OK.

Practica ls


10. This window shows the configuration for dynamic NATing with the address pool. Click Designate NAT

Use this window to designate the inside and outside interfaces that you want to use in NAT translations. NAT uses the inside and outside designations when it interprets translation rules, because translations are performed from inside to outside, or from outside to inside. Once designated, these interfaces are used in all NAT translation rules. The designated interfaces appear above the Translation Rules list in the main NAT window.


Practica ls

Static NAT Configuration
Complete these steps in order to configure static NAT in a Cisco router.

1. Choose Configure > NAT > Edit NAT Configuration and click Add in order to configure static NATing.

2. Choose the Direction either from inside to outside or from outside to inside, specify the inside IP address
to be translated under Translate from Interface. For the Translate to Interface area select the Type.

Choose IP Address if you want the Translate from Address to be translated to an IP address defined in the IP Address field. Choose Interface if you want the Translate from Address to use the address of an interface on the router. The Translate from Address is translated to the IP address assigned to the interface that you specify in the Interface field.


Check Redirect Port if you want to include port information for the inside device in the translation. This enables you to use the same public IP address for multiple devices, as long as the port specified for each device is different. You must create an entry for each port mapping for this Translated to address. Click TCP if this is a TCP port number and click UDP if it is a UDP port number. In the Original Port field, enter the port number on the inside device. In the Translated Port field, enter the port number that the router is to use for this translation. Refer to the Allowing the Internet to Access Internal Devices section of Configuring Network Address Translation: Getting Started.

Practica ls


This window shows the static NATing configuration with port redirection enabled.


Practica ls

Routing Configuration

Static Routing Configuration
Complete these steps in order to configure static routing in a Cisco router.

1. Choose Configure > Routing > Static Routing and click Add in order to configure static routing.

2. Enter the Destination Network address with mask and select either outgoing interface or next hop IP address.

Practica ls


This window shows the static route configured for the network with as the next hop IP address.

Dynamic Routing Configuration
Complete these steps in order to configure the dynamic routing in a Cisco router.

1. Choose Configure > Routing > Dynamic Routing. 2. Select the RIP and click Edit.

3. Check Enable RIP, select the RIP version, and click Add.


Practica ls

4. Specify the Network address to be advertised.

5. Click OK.

Practica ls


6. Click Deliver in order to transfer the commands to the router.


Practica ls
This window shows the dynamic RIP routing configuration.

Miscellaneous Configuration
Complete these steps in order to configure the other basic settings in a Cisco router.

1. Choose Configure > Additional Tasks > Router Properties and click Edit if you want to change the
Hostname, Domain Name, Banner and Enable Secret Password properties for a router.

2. Choose Configure > Additional Tasks > Router Access > User Accounts/View in order to add/edit/delete
the User Accounts to the router.

Practica ls


3. Choose File > Save Running Config to PC... in order to save the configuration to the NVRAM of the
router as well as the PC and to reset the current configuration to default (factory) settings.


Practica ls

4. Go to the task bar and choose Edit > Preferences in order to enable these User Preferences options:
o o o o

Preview commands before delivering to router. Save signature file to Flash. Confirm before exiting from SDM. Continue monitoring interface status when switching mode/task.

5. Choose View from the task bar if you want to:

View the Home, Configure, or Monitor pages.

Practica ls
o o o o


View the running configuration of the router. View various show commands. View SDM default rules. Choose Refresh in order to synchronize the router configuration if there are any configured through the CLI with SDM.


Practica ls