... # Follow all the steps listed in the preceding section for installing certificate files on the GDMA client.
# Start (or restart, on Windows) the GDMA client.
Note that command-line options are available for unattended-mode installs, for selecting the installation mode, target server name, communication protocol, and (on non-Windows platforms) whether to start the service at the end of the install, as well as other parameters you may wish to set. Run the installer with the {{\--help}} option to see these options listed.
h4. 5.0 Maintaining the HTTPS Setup
Starting with the GDMA 2.3.2 release, a GDMA client that wants to perform various configuration-related interactions with the GWMEE server via HTTPS must have a valid SSL certificate and (optionally) a valid certificate revocation list (CRL) in place. Reporting of monitoring results is done via a separate channel, which is not dependent on the SSL certificate files. (This channel can also be encrypted if you wish, but that is a separate setup issue.)
From time to time, you may find it necessary to replace the SSL certificate file in use within your infrastructure. SSL certificates may exceed their useful lifetimes in several different ways, among them:
* The certificate will shortly reach its manufactured expiration time.
* You decide that you want to stop using a particular certificate, for reasons beyond the validity, duration, or current trust level of the certificate. For instance, perhaps you are going to change your master Certificate Authority in a month's time, and you want to switch all your clients to using a certificate derived from the new Certificate Authority. Since you had the foresight and energy to make this happen ahead of time, the old certificate remains valid and useable throughout the transition period.
* The private key on your GWMEE server has been compromised or stolen, or perhaps some upstream key related to your Certificate Authority has been so compromised.
We will classify the first two of those cases as "planned" invalidation of the certificate. We will classify the last case as an "unplanned" invalidation of the certificate. Your response to these two types of invalidation will be very different.
You might also just need to update the CRL file, if it expires but the certificate itself is still valid. In this case, you can just generate a new CRL and install it on your clients, without swapping in a new certificate as well. You will need to run {{c_rehash}} in the usual manner on each client after the new CRL is in place, to generate the usual necessary symlinks for the CRL to be recognized.
h5. 5.1 Revoking an SSL certificate (general discussion)
If a private key gets compromised or stolen, or the chain of trust starting with your Certificate Authority is otherwise compromised, you should revoke any related certificates so the clients can no longer use them. (Based strictly on their manufactured lifetimes, such certificates will otherwise still be valid.) Revoked certificates (e.g., those you wish to disallow because they were manufactured based on the server's compromised private key) are only known to each client to have been revoked because they are stored in a Certificate Revocation List (CRL) on that client. The client references its local CRLs when making a connection to the server. Thus in this situation, the CRL will need to be updated on each and every GDMA client, along with having a new, valid certificate installed.
{note:title=CRL files are important}
If the client is somehow repopulated with an old certificate and still has an out-of-date CRL, a man-in-the-middle (MITM) attack is possible. So for proper security, distributing an updated CRL file is just as important as distributing a new certificate file.
{note}
{warning:title=SSL certificate management is critical}
Notwithstanding what we said in the note just above, GroundWork is not convinced that CRL files do the job they're supposed to, in preventing unwanted attacks. So it is best not to depend on them, and to ensure that you manage your SSL certificates properly on both the server and your GDMA clients. On the server, you should have only one certificate in play at any one time. On each client, keep only the current valid certificate that the server accepts, and no others except during server transition periods when you briefly have a new certificate installed on the client before the server is transitioned, and an old certificate still installed on the client after the server is transitioned.
The GDMA 2.3.2 client software does not insist on the use of CRL files. If any are present, they will be used, to whatever effect they have on the operation of the SSL libraries. If no CRL files are present, the GDMA client software will simply skip CRL processing.
{warning}
To revoke a certificate, you must do several things. Details and proper sequencing are provided below this overview.
# If the certificate to be revoked is your own, remove the certificate from the server, so client connections can no longer validate against it. (This step alone doesn't prevent a MITM attacker from using the certificate, though, which is why you should continue on and update the client CRL.)
# If your own private server key has been compromised, you will need to generate a new one, and use it for all subsequent operations regarding maintenance of certificate and CRL files.
# Put in place on the server a replacement certificate, as needed. In particular, if it is your own self-signed certificate that you are revoking, you will need to generate a new self-signed certificate before you can revoke the old one. See the commands below.
# Add the revoked certificate to your master certificate revocation list (see detailed commands below for how to do this if you are using self-signed certificates). This is especially important if the certificate to be revoked arose from some third-party intrusion, in which case you do not necessarily have access to the intruder's server to remove the certificate there.
# Tell the clients to use the new certificate (known as {{server.crt}} on your server), by installing your renamed and numbered copy on every client (for example, as {{server_02.pem}}, in the {{gdma/certs/}} directory).
# Tell the clients not to use the revoked certificate, firstly by removing the old certificate file (e.g., {{server_01.pem}}) from every client, and also (if you choose to use CRLs) by distributing the updated certificate revocation list (e.g., {{crl_02.pem}}) to every client (also in the client's {{gdma/certs/}} directory). The latter step should block any attempt by a rogue server to use the revoked certificate.
# On each client, run the {{c_rehash}} program as you did when initially setting up the client to use HTTPS. This will maintain the necessary symlinks to or copies of the certificate and revocation-list files.
# You may then choose to stop and start GDMA on the client, so it will reinitialize itself using the new setup. (Strictly speaking, this should not be necessary, because the HTTPS connections are short-lived. Thus there should be no long-lasting connection you need to break by bouncing the client, and the next connection attempt should simply use the new setup, without further ado. Bouncing the client is simply precautionary.)
Commands used to revoke a certificate and to add the revoked certificate to your revocation list are shown in full context within the following two sections, on planned and unplanned certificate invalidation. The commands are sequenced to keep the bad old certificate around long enough to extract information from it for the revoking, and to have in place a good new certificate to use during the revocation processing. For sites using self-signed certificates, the commands result in an updated revocation list (e.g., {{crl_02.pem}}) that is distributed to your clients along with the new certificate (e.g., {{server_02.pem}}).
If you're curious about what certificates (if any) have been revoked, you can peek inside the CRL file using commands like this, naming the particular CRL file you are interested in (e.g., {{crl_02.pem}}):
{code:none}
cd /usr/local/groundwork/apache2/conf
/usr/local/groundwork/common/bin/openssl crl -noout -text -in crl_02.pem
{code}
With that general background, we now present the full series of commands you will need in the two major scenarios of planned and unplanned certificate invalidation.
h5. 5.2 Planned certificate invalidation
For a planned invalidation, you have time to make the transition, and should take the following steps:
# Obtain or create a new server certificate (and perhaps a new private key preceding that, if desired), _but do not install those files yet on the server using the standard filenames which would place these files into active service_. You want your GDMA clients to continue to use their existing copies of the old certificate during the transition period, and for this to happen, the server must continue to use the old files. *Be sure to alter the target filenames in any commands you use to generate such files, so you do not overwrite the existing files.* In the sample commands below, we have altered the filenames in accordance with that dictum, but you must still watch out for filenames with embedded serial numbers, and make appropriate adjustments. Perform these steps on the GroundWork server, as the {{nagios}} user.
{code:none}
# Get to where the certificate files lie, to make these commands easier.
cd /usr/local/groundwork/apache2/conf
# First, copy the old certificate, keeping it around under an obvious
# name so it's clear what you're doing when you formally revoke it
# (that is, when you put it in your certificate revocation list).
cp -p server.crt server_old.crt
# Create a symlink to refer to the server key that will be used once
# the new certificate is in place. Referring to this symlink simplifies
# the multiple cases we are covering here.
ln -s server.key server.key.future
# If desired, create a new private server key, using these commands.
# Otherwise, skip these commands and go directly to obtaining or
# creating a new server certificate.
rm server.key.future
/usr/local/groundwork/common/bin/openssl genrsa -out server.key.new 2048
ln -s server.key.new server.key.future
# If you obtain a new certificate from a Certificate Authority, install
# it in this directory on your server as the "server.crt.new" file.
# Otherwise (that is, if you do not obtain a new certificate from a
# Certificate Authority), create a new self-signed server certificate
# this way, adjusting the -days parameter (time until certificate
# expiration) as desired. Here in this sample command, we specify a
# three-year lifetime.
/usr/local/groundwork/common/bin/openssl req -new -x509 \
-key server.key.future -out server.crt.new -days 1095 \
-set_serial `date +%s`
# Copy the new server certificate into a serial-numbered name that
# will be more useful later on, on your clients. When you type this
# command, choose the next unused serial number in sequence at your
# site for such files. For example, if server_01.pem already exists,
# you might type:
cp -p server.crt.new server_02.pem
{code}
# Visit each and every GDMA client in turn, and take these steps:
## Install the new certificate (e.g., {{server_02.pem}}, in this example), leaving the old certificate (and revocation list, if any) still in place for the time being. This file will go into the {{gdma/certs/}} directory, right next to your existing certificate-related files.
## On a UNIX-like GDMA client platform, make sure the certificate file is owned by either {{root}} or the user that owns all the rest of the GDMA files (typically, {{gdma}}), and that the new file has only {{644}} permissions. (Logically, you want to do the same thing on Windows platforms. However, specifying the Windows commands to do so is beyond the scope of this document. At a minimum, you probably want to use "{{attrib \+r}} _filenames_" to make the certificate-related files read-only.)
## After you install the new certificate file on each client, run {{c_rehash}} on the client to generate hash values for all the certificate-related files on the client, both old and new. This will set up the client for the actual transition on the server ("flag day").
##* On a Windows system, the commands would be like:
{code:none}
cd {path-to}\gdma\certs
..\..\common\bin\c_rehash
{code}
##* On a Linux or AIX system, the commands would be:
{code:none}
cd /usr/local/groundwork/gdma/certs
../../common/bin/c_rehash ./
{code}
##* On a Solaris system, the commands would be:
{code:none}
cd /opt/groundwork/gdma/certs
../../common/bin/c_rehash ./
{code}
# When flag day arrives, perform the following actions on the GroundWork server. Except where noted, run these commands as the {{nagios}} user.
## If you will be distributing CRL files to your GDMA clients, generate a revised certificate revocation list that includes the old certificate. The process for doing so if you are getting your certificates from an outside source is beyond the scope of this article. The commands for doing so if you are using self-signed certificates are presented here.
{code:none}
# Get to where the certificate files lie, to make these commands easier.
cd /usr/local/groundwork/apache2/conf
# Extract details of the old certificate into your permanent store of
# revoked certificates (/usr/local/groundwork/common/openssl/index.txt,
# as specified in the openssl.cnf file in that same directory).
/usr/local/groundwork/common/bin/openssl ca -revoke server_old.crt \
-keyfile server.key.future -cert server.crt.new
# Generate a new revocation list, one that will now contain a description
# of the certificate you just revoked (in addition to descriptions of any
# previously revoked certificates). Modify the command shown here to set
# the -crldays parameter to whatever period makes sense, as noted earlier.
/usr/local/groundwork/common/bin/openssl ca -gencrl \
-keyfile server.key.future -cert server.crt.new \
-out crl_`cat ../../common/openssl/crlnumber`.pem -crldays 1095
{code}
The odd construction of the {{\-out}} parameter in the last command will have created a serial-numbered file such as {{crl_02.pem}} as the new CRL file.
## Shut down the GroundWork software before you change the certificate, as the change will disrupt ordinary operation.
{code:none}
su - root
service groundwork stop gwservices
service groundwork stop apache
exit
{code}
## Put the new certificate (and the private key, if you are replacing that as well) into play with Apache.
{code:none}
# Get to where the certificate files lie, to make these commands easier.
cd /usr/local/groundwork/apache2/conf
# If you will continue to use the same private server key, just skip
# this command. Otherwise, you created a new private server key in
# the first step. Now is the time to put it into place, thereby
# destroying the old one, with the following command.
mv server.key.new server.key
Move the new certificate into place, thereby destroying the old one.
mv server.crt.new server.crt
# Clean up the scaffolding you created in earlier steps.
rm server.key.future
rm server_old.crt
{code}
## Delete the old certificate from the Java keystore. *"gwservername" in the* {{*\-delete{*}}} *command here must be the same name you used when you installed the old certificate in the keystore.* Each of the {{keytool}} commands will prompt for a password; by default, it is {{changeit}} .
{code:none}
# You can verify the existing "gwservername" value in your Java keystore
# by examining the output from the following command.
/usr/local/groundwork/java/bin/keytool -list \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts \
| fgrep `hostname | sed -e 's/\..*//'`
# Delete the old certificate from the Java keystore. Modify the command
# shown here to substitute in the proper alias for "gwservername" on
# your system, exactly matching the server name in the certificate you
# are deleting.
/usr/local/groundwork/java/bin/keytool -delete -alias gwservername \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts
{code}
## Put the new certificate into the Java keystore. *As above, modify "gwservername" in the* {{*\-import{*}}} *command here to mention your own server name.*
{code:none}
# Modify the command shown here to substitute in the proper alias for
# "gwservername" on your system, exactly matching the server name in
# the new certificate you are adding.
/usr/local/groundwork/java/bin/keytool -import -alias gwservername \
-file /usr/local/groundwork/apache2/conf/server.crt \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts
{code}
## Restart the GroundWork software, to operate with the new certificate in play.
{code:none}
su - root
service groundwork start apache
service groundwork start gwservices
exit
{code}
# Once the server has been so converted, go back to each and every GDMA client in turn, and take the following steps:
## Delete the old certificate (e.g., {{server_01.pem}}) from the {{gdma/certs/}} directory.
## If you are supporting CRL files on your clients, install the updated revocation list (e.g., {{crl_02.pem}}) in the {{gdma/certs/}} directory. You can leave older CRLs in place; there is no particular reason to delete them.
## If you are supporting CRL files on your clients, then on a UNIX-like platform, make sure the new CRL is owned by either {{root}} or the usual GDMA user (typically, {{gdma}}), and that it has only 644 permissions. (Logically, you want to do the same thing on Windows platforms. However, specifying the Windows commands to do so is beyond the scope of this document. At a minimum, you probably want to use "{{attrib \+r}} _filenames_" to make the certificate-related files read-only.)
## Run {{c_rehash}} to establish hashes for all the presently installed files, using the commands shown above for this type of platform.
h5. 5.3 Unplanned certificate invalidation
For an unplanned invalidation, trust has been lost, so you have a security crisis to deal with, and your response must be immediate and severe. The certificate whose chain of trust has been compromised must be immediately revoked, so it is no longer used by your clients. In this situation, you must take the following steps, as the {{nagios}} user:
# Obtain or create a new certificate (and perhaps a new private key preceding that, if appropriate, depending on what has been compromised). If obtaining a new certificate from an external Certificate Authority may take some time, you might consider using a self-signed certificate on a temporary basis, so you can stop using the old certificate immediately but still allow browser-based access to GroundWork Monitor until the situation can be fully corrected. Perform these steps on the GroundWork server.
{code:none}
# Get to where the certificate files lie, to make these commands easier.
cd /usr/local/groundwork/apache2/conf
# First, copy the bad certificate, keeping it around under an obvious
# name so it's clear what you're doing when you formally revoke it
# (that is, when you put it in your certificate revocation list).
cp -p server.crt server_bad.crt
# Create a symlink to refer to the server key that will be used once
# the new certificate is in place. Referring to this symlink simplifies
# the multiple cases we are covering here.
ln -s server.key server.key.future
# If necessary (e.g., if the private server key has been compromised),
# or if otherwise desired, create a new private server key, using these
# commands. Otherwise, skip these commands and go directly to obtaining
# or creating a new server certificate.
rm server.key.future
/usr/local/groundwork/common/bin/openssl genrsa -out server.key.new 2048
ln -s server.key.new server.key.future
# If you obtain a new certificate from a Certificate Authority, install
# it in this directory on your server as the "server.crt.new" file.
# Otherwise (that is, if you do not obtain a new certificate from a
# Certificate Authority), create a new self-signed server certificate
# this way, adjusting the -days parameter (time until certificate
# expiration) as desired. Here in this sample command, we specify a
# three-year lifetime.
/usr/local/groundwork/common/bin/openssl req -new -x509 \
-key server.key.future -out server.crt.new -days 1095 \
-set_serial `date +%s`
# Copy the new server certificate into a serial-numbered name that
# will be more useful later on, on your clients. When you type this
# command, choose the next unused serial number in sequence at your
# site for such files. For example, if server_01.pem already exists,
# you might type:
cp -p server.crt.new server_02.pem
{code}
# If you will be distributing CRL files to your GDMA clients, generate a revised certificate revocation list that includes the old certificate. The process for doing so if you are getting your certificates from an outside source is beyond the scope of this article. The commands for doing so if you are using self-signed certificates are presented here; run these commands on the GroundWork server, as the {{nagios}} user.
{code:none}
# Get to where the certificate files lie, to make these commands easier.
cd /usr/local/groundwork/apache2/conf
# Extract details of the bad certificate into your permanent store of
# revoked certificates (/usr/local/groundwork/common/openssl/index.txt,
# as specified in the openssl.cnf file in that same directory).
/usr/local/groundwork/common/bin/openssl ca -revoke server_bad.crt \
-keyfile server.key.future -cert server.crt.new
# Generate a new revocation list, one that will now contain a description
# of the certificate you just revoked (in addition to descriptions of any
# previously revoked certificates). Modify the command shown here to set
# the -crldays parameter to whatever period makes sense, as noted earlier.
/usr/local/groundwork/common/bin/openssl ca -gencrl \
-keyfile server.key.future -cert server.crt.new \
-out crl_`cat ../../common/openssl/crlnumber`.pem -crldays 1095
{code}
The odd construction of the {{\-out}} parameter in the last command will have created a serial-numbered file such as {{crl_02.pem}} as the new CRL file.
# In this step, you will switch the certificate (and the private key, if you are replacing that as well) on the server. This will immediately stop all clients from being able to access the server for configuration-related information. GDMA clients should continue to monitor their respective environments and report back results from this point forward, but their configurations will be frozen for the time being. Ordinary browser clients will probably need to have their local certificate stores manually flushed to drop the old certificate, using whatever preference-editing mechanisms are provided by the browser. Perform the following actions on the GroundWork server. Except where noted, run these commands as the {{nagios}} user.
## Shut down the GroundWork software before you change the certificate, as the change will disrupt ordinary operation. (You cannot even remove the bad certificate before this step, as having it missing would prevent you from stopping Apache now\!)
{code:none}
su - root
service groundwork stop gwservices
service groundwork stop apache
exit
{code}
## Put the new certificate (and the private key, if you are replacing that as well) into play with Apache.
{code:none}
# Get to where the certificate files lie, to make these commands easier.
cd /usr/local/groundwork/apache2/conf
# If you will continue to use the same private server key, just skip
# this command. Otherwise, you created a new private server key in
# the first step. Now is the time to put it into place, thereby
# destroying the old one, with the following command.
mv server.key.new server.key
Move the new certificate into place, thereby destroying the old one.
mv server.crt.new server.crt
# Clean up the scaffolding you created in earlier steps.
rm server.key.future
rm server_bad.crt
{code}
## Delete the old certificate from the Java keystore. *"gwservername" in the* {{*\-delete{*}}} *command here must be the same name you used when you installed the old certificate in the keystore.* Each of the {{keytool}} commands will prompt for a password; by default, it is {{changeit}} .
{code:none}
# You can verify the existing "gwservername" value in your Java keystore
# by examining the output from the following command.
/usr/local/groundwork/java/bin/keytool -list \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts \
| fgrep `hostname | sed -e 's/\..*//'`
# Delete the old certificate from the Java keystore. Modify the command
# shown here to substitute in the proper alias for "gwservername" on
# your system, exactly matching the server name in the certificate you
# are deleting.
/usr/local/groundwork/java/bin/keytool -delete -alias gwservername \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts
{code}
## Put the new certificate into the Java keystore. *As above, modify "gwservername" in the* {{*\-import{*}}} *command here to mention your own server name.*
{code:none}
# Modify the command shown here to substitute in the proper alias for
# "gwservername" on your system, exactly matching the server name in
# the new certificate you are adding.
/usr/local/groundwork/java/bin/keytool -import -alias gwservername \
-file /usr/local/groundwork/apache2/conf/server.crt \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts
{code}
## Restart the GroundWork software, to operate with the new certificate in play.
{code:none}
su - root
service groundwork start apache
service groundwork start gwservices
exit
{code}
# Visit each and every GDMA client in turn, and take these steps:
## Delete the old certificate (e.g., {{server_01.pem}}) from the {{gdma/certs/}} directory.
## If you are supporting CRL files on your clients, install the updated revocation list (e.g., {{crl_02.pem}}) in the {{gdma/certs/}} directory. You can leave older CRLs in place; there is no particular reason to delete them.
## Install the new certificate (e.g., {{server_02.pem}} in this example) in the {{gdma/certs/}} directory.
## On a UNIX-like platform, make sure the new files are owned by either {{root}} or the usual GDMA user (typically, {{gdma}}), and that they have only 644 permissions. (Logically, you want to do the same thing on Windows platforms. However, specifying the Windows commands to do so is beyond the scope of this document. At a minimum, you probably want to use "{{attrib \+r}} _filenames_" to make the certificate-related files read-only.)
## Run {{c_rehash}} to establish a current set of hashes, using the commands shown above for this type of platform.
During an unplanned invalidation, the GDMA clients will continue to report monitoring results for some period, set by the {{Poller_Pull_Failure_Interval}} as configured on each client. This parameter is set to {{86400}} (seconds), or one day, in the standard distributed {{gdma_auto.conf}} file. For details, see the description of this option in the [Configuration Reference] page of the Bookshelf. This is how long you will have to update all of your clients with a new certificate before they go dark from a monitoring-results standpoint.
{note:title=Be Prepared}
Because of this limited time period, you must be ready with a procedure to generate or procure a new certificate, and update *all* your GDMA clients quickly, well in advance of any emergency situation. You may extend this period (preferably in advance of an actual emergency) by changing the {{Poller_Pull_Failure_Interval}} setting. This can be especially important on GDMA clients which for some reason are hard to reach for maintenance purposes.
{note}
h4. 6.0 Troubleshooting an HTTPS Connection
Very little information is provided by the HTTPS-support software when the certificate and certificate revocation list do not work as intended. If you enable logging in the GDMA poller, via the {{Enable_Local_Logging}} option in the {{gdma_auto.conf}} file, a small amount of information may be gleaned. Here is an example, with the lines wrapped for easier viewing here:
{code:none}
[Thu Apr 4 16:55:52 2013] Failed to get https://gwserver/gdma/gwmon_linuxgdma.mydomain.com.cfg --
500 Can't connect to gwserver:443 (certificate verify failed)
[Thu Apr 4 16:55:52 2013] Failed to get https://gwserver/gdma/gwmon_linuxgdma.cfg --
500 Can't connect to gwserver:443 (certificate verify failed)
[Thu Apr 4 16:55:52 2013] Failed to fetch the host config file.
[Thu Apr 4 16:55:52 2013] ERROR: Auto-registration request was not processed;
HTTP/S response code = 500.
[Thu Apr 4 16:55:52 2013] XML response was:
Can't connect to work.groundwork.groundworkopensource.com:443 (certificate verify failed)
LWP::Protocol::https::Socket: SSL connect attempt failed with unknown error error:
14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at
/usr/local/groundwork/perl/lib/site_perl/5.8.9/LWP/Protocol/http.pm line 51.
{code}
The phrase "certificate verify failed", repeated several times as shown above, is as much detail as you're going to get. So it's important to follow the certificate-install instructions carefully on every GDMA client. The main things to check are:
* Is the certificate file (e.g., {{server_01.pem}}) in place on the client, in the {{gdma/certs/}} directory, with restricted ownership and permissions?
* If you are supporting CRL files on your clients, is the certificate revocation list (e.g., {{crl_01.pem}}) also in place on the client, in the {{gdma/certs/}} directory, with restricted ownership and permissions?
* Is the certificate file up-to-date with the current copy on the server?
* If you are supporting CRL files on your clients, is the certificate revocation list file up-to-date with the current copy on the server?
* Does the certificate reflect the actual hostname used by the server?
* Does the {{Target_Server}} option in the client {{gdma_auto.conf}} file reflect the exact same form of the hostname as is present in the certificate?
* Have the appropriate hash symlinks or copies been made in the {{gdma/certs/}} directory, using the {{c_rehash}} program?
If all of those things check out, perhaps you really do have a Man-In-The-Middle attack going on, and the client _should not_ be validating the certificate under that condition\! (Proving that such a situation is happening is beyond the scope of this document. Consult your local network folks.)
|
E-mail