In Web-based System Manager secure operation, the managed AIX machines are servers, and the managing users are the clients. The communication between the servers and clients is over the SSL protocol which provides server authentication, data encryption, and data integrity. The user manages the AIX machine by Web-based System Manager using an AIX account on that machine, and authenticates to the Web-based System Manager server by sending the user ID and password over the secured SSL protocol.
Each Web-based System Manager server has its private key and a certificate of its public key signed by a Certificate Authority (CA) which is trusted by the Web-based System Manager clients. The private key and the server certificate are stored in the server's private key ring file /usr/websm/security/SM.privkr. The Web-based System Manager client has public key ring file which contains the certificates of the CAs it trusts. This file is SMpubkr.class. It is a .class file so that the same file may be used both for application and applet modes.
In applet mode (working from the browser), the client must be assured that the applet (.class files) arriving at the browser is coming from the intended server. Moreover, in this mode the public key ring file (SMpubkr.class) resides on the server and is transferred to the client with the rest of the applet .class files (it is done this way because the browser does not allow applets to read local files). For sender authentication and integrity of these files the client must use the SSL capabilities of the browser and contact the server only with the HTTPS protocol (HTTPS://...). For this you can use the SSL capability of the web server on each managed machine or you can use the SMGate daemon installed with Web-based System Manager Security. SMGate serves as an SSL gateway between the client browser and the web server.
In this section, the following procedures and processes related to Security are discussed at length:
Web-based System Manager Security's pre-requisite is the Web-based System Manager. The Web-based System Manager Security fileset, sysmgt.websm.security, where available, can be found on the AIX Version 4.3 Bonus Pack.
An additional fileset, sysmgt.websm.security-us, with stronger encryption capabilities, is available on the AIX Version 4.3 Bonus Pack that ships only in the U.S. and Canada. This fileset requires that you have sysmgt.websm.security.
The following scenarios or configuration possibilities are outlined:
You should use a 'safe' system for the CA. The CA's private key is the most sensitive data in the Web-based System Manager security configuration.
Once the CA machine is chosen, log on locally as root and start the Web-based System Manager. The security configuration applications of the Web-based System Manager are not accessible if you are not logged in as root or if you are running the Web-based System Manager in remote application or applet mode.
Open the "System" container and find the security configuration objects, "Certificate Authority" and "Server Security".
On the object menu for "Certificate Authority" select "Configure this System as Certificate Authority ...". This will start a task guide. Fill in the following information:
Certificate Authority distinguished name
Enter a descriptive name that will help you identify
the CA machine and the instance of the CA. Blanks are
permitted in the name. The machines hostname plus a
sequence number would be a good choice. If you ever
redefine the CA, use a different sequence number so you
will be able to determine which instance of the CA a
certificate is signed by. The name should not be exactly
the same as the full TCP/IP name as this will not work with
the SMGate utility.
Organization name
Enter a descriptive name that identifies your company
or your organization.
ISO country code
Enter your 2 character ISO country code or select it
from the list.
Expiration date
After the expiration date you will need to re-configure
Web-based System Manager Security, that is, you will
need to re-define the CA and generate new private key
ring files for all of your servers. You can change this
date or accept the default value.
Public key ring directory
This is the directory where the public key ring
containing the CA's certificate will be written. You
will need to copy this file to the /usr/websm/codebase
directory on all of the Web-based System Manager servers and
clients.
Password
The CA's private key ring file (/usr/websm/security/SM.caprivkr)
will be encrypted with this password. Remember this
password. You will need to enter it each time you perform
a task on this CA.
You can perform this task from the command line with the smdefca command.
In this step you will need to provide the the full TCP/IP names of all of your Web-based System Manager servers. You can enter them in the dialog one at a time or you can provide a file containing a list of your servers, one per line.
On the object menu for "Certificate Authority" select "Generate Servers' Private Keys and Certificate Requests ...". The CA password dialog will appear first. Enter the password that you specified when you defined the CA. Then fill in the following information:
List of servers
Add the names of your Web-based System Manager servers to
the list. You can enter them in the dialog one at a time or
you can provide a file containing a list of your servers, one
per line. To get the server names from the file, enter the
file name in the "File containing list of servers" entry field
and click the "Browse file" button. The "Browse Server List
File dialog" will allow you to select some or all of the servers
in the list.
Organization name
Enter a descriptive name that identifies your company
or your organization.
ISO country code
Enter your 2 character ISO country code or select it
from the list.
Location for private key ring files
Enter the directory where you want the server private
key ring files written. Later, you will need to
distribute them to the servers and install them.
Expiration date
After the expiration date you will need to generate
new private key ring files for your servers. You can change
this date or accept the default.
Length in bits of server keys
Select a key length (this field only appears if you have
the sysmgt.websm.security-us fileset installed).
Encrypt the server private key ring files
This dialog creates a private key ring file for each
server that you specified. Each private key ring file
contains the private key of a server. If someone steals
this key he gains the power of pretending to be that server.
Thus this file should be always kept protected.
You can protect the private key ring files by encrypting
them. If you select this option, you will be prompted for
a password. Remember this password. You will be asked for
it when you install the private key rings on the servers.
When you click OK, a private key ring file (S.privkr) is created for each server, (S) that you specified.
You can perform this task from the command line with the smgenprivkr command.
A copy of SMpubkr.class from the directory you specified in step I must be placed in the /usr/websm/codebase directory of your Web-based System Manager servers and AIX clients.
Note: The content of this file is not secret. However, placing it on a client machine specifies which CA the client trusts. Thus access to this file on the client machine should be limited. In applet mode, the client can trust the server to send over this file along with the applet itself - provided the HTTPS protocol is used.
Each server's private key ring file must be installed on the server.
You can move the files to their targets in any secure way. We'll describe here two ways - shared directory and diskette TAR:
Place all of the key ring files on a shared directory (e.g. NFS, DFS) accessible to each server.
Note: For this method you should have chosen to encrypt the server private key ring files on the Generate Servers Private Key Ring Files dialog, since the files will be transferred in the clear. It is also recommended to restrict the access rights to the shared directory to the administrator.
Generate a diskette TAR containing all of the server private key ring files. The TAR archive should contain just the file names without the paths. To do this, change directories to the directory containing the server private key ring files and run the command tar -cvf /dev/fd0 *.privkr.
Next you will need to install the server private key rings on each server. Log on to each server as root, start the Web-based System Manager and open the System container. On the object menu for "Server Security" select "Install Private Key Ring...". Select the source for the server private key ring files. If using a diskette TAR, insert the diskette before clicking OK. Now go ahead and click on OK. If the key ring files are encrypted, you will be asked for the password. The servers private key is installed in /usr/websm/security/SM.privkr. Repeat this procedure on each server.
You can perform this task from the command line with the sminstkey command.
For servers in site B follow these steps:
In this step you will need to provide the the full TCP/IP names of all of your Web-based System Manager servers in site B. You can enter them in the dialog one at a time or you can provide a file containing a list of your servers, one per line.
On a server in site B, log on locally as root and start the Web-based System Manager. The security configuration applications of the Web-based System Manager are not accessible if you are not logged in as root or if you are running the Web-based System Manager in remote application or applet mode.
Open the "System" container and find the security configuration object "Server Security".
On the object menu for "Server Security" select "Generate Servers' Private Keys and Certificate Requests...". Fill in the following information:
List of servers
Add the names of your Web-based System Manager servers in
site B to the list. You can enter them in the dialog one at
a time or you can provide a file containing a list of your
servers, one per line. To get the server names from the file,
enter the file name in the "File containing list of servers"
entry field and click the "Browse file" button. The "Browse
Server List File dialog" will allow to select some or all of
the servers in the list.
Organization name
Enter a descriptive name that identifies your company
or your organization.
ISO country code
Enter your 2 character ISO country code or select it
from the list.
Location for private key files and certificate requests
Enter the directory where you want the server private
key files and certificate requests written. In Step II,
you will need to transfer the certificate request files to
the CA in site A for signing. In Step III, you will
need to transfer the signed certificates from the CA in
Site A back to this directory.
Length in bits of server keys
Select a key length (this field only appears if you have
the sysmgt.websm.security-us fileset installed).
Encrypt the server private key files
This dialog creates a private key file for each
server that you specified. Each private key file
contains the private key of the server. If someone steals
this key he gains the power of pretending to be that server.
Thus this file should be always kept protected.
You can protect the private key ring files by encrypting
them. If you select this option, you will be prompted for
a password. Remember this password. You will be asked for
it when you import the signed certificates and when you
install the private key rings on the servers.
When you click OK, a private key ring file (S.privk) and a certificate request (S.certreq) is created for each server, (S) that you specified.
You can perform this task from the command line with the smgenkeycr command.
In this step you need to transfer the certificate request files to the CA in site A. The certificate requests do not contain secret data, however, the integrity and authenticity during transfer must be insured.
Transfer a copy of the certificate request files from the server in site B to a directory on the CA machine in site A.
Log on to the CA machine in site A locally as root and start the Web-based System Manager. The security configuration applications of the Web-based System Manager are not accessible if you are not logged in as root or if you are running the Web-based System Manager in remote application or applet mode.
Open the "System" container and find the security configuration object "Certificate Authority".
On the object menu for "Certificate Authority" select "Sign Certificates...". Fill in the following information:
Directory for certificate requests
Enter the directory containing the certificate requests.
Then click the "Update List" button. The certificate
request list will appear in the list box.
Select certificate requests to sign
To select individual certificate requests, click
on them in the list box. To select all of the listed
certificate requests, click the "Select All" button.
Certificate Expiration Date
After the expiration date you will need to repeat this
process to generate new private key ring files for your
servers. You can change this date or accept the default
date.
When you click OK, a certificate file (S.cert) is created for each server (S) that you selected. The certificates are written to the directory containing the certificate requests.
You can perform this task from the command line with the smsigncert command.
In this step you need to transfer the certificates from the CA in site A back to the server in site B. Copy them to the directory containing the certificate requests and server private key files that you created in step I.
Then on the server in site B, from the object menu for "Server Security", select "Import Signed Certificates...".
Fill in the following information:Directory for certificates and private keys
Enter the directory containing the signed certificates
and server private key files. Then click the "Update List"
button. The list of servers for which there is a signed
certificate and a private key file will appear in the
list box.
Select one or more servers from the list
To select individual servers, click on them in the list box.
To select all of the listed servers, click the "Select All"
button.
When you click OK, if the server private key files were encrypted in step I, you will be prompted for the password. Then, for each server (S) that you selected, the certificate (S.cert) is imported in to the private key file (S.privk) and the private key ring file (S.privkr) is created.
You can perform this task from the command line with the smimpservercert command.
Each server's private key ring file must be installed on the server.
You can move the files to their targets in any secure way. We'll describe here two ways - shared directory and diskette TAR:
Place all of the key ring files on a shared directory (e.g. NFS, DFS) accessible to each server.
Note: For this method you should have chosen to encrypt the server private key ring files on the Generate Servers Private Key Ring Files dialog, since the files will be transferred in the clear. It is also recommended to restrict the access rights to the shared directory to the administrator.
Generate a diskette TAR containing all of the server private key ring files. The TAR archive should contain just the file names without the paths. To do this, change directories to the directory containing the server private key ring files and run the command tar -cvf /dev/fd0 *.privkr.
Next you will need to install the server private key rings on each server. Log on to each server as root, start the Web-based System Manager and open the System container. On the object menu for "Server Security" select "Install Private Key Ring...". Select the source for the server private key ring files. If using a diskette TAR, insert the diskette before clicking OK. Now go ahead and click on OK. If the key ring files are encrypted, you will be asked for the password. The servers private key is installed in /usr/websm/security/SM.privkr. Repeat this procedure on each server.
You can perform this task from the command line with the sminstkey command.
A copy of SMpubkr.class from the directory you specified in step I must be placed in the /usr/websm/codebase directory of your Web-based System Manager servers and AIX clients.
Note: The content of this file is not secret. However, placing it on a client machine specifies which CA the client trusts. Thus access to this file on the client machine should be limited. In applet mode, the client can trust the server to send over this file along with the applet itself - provided the HTTPS protocol is used.
Before you follow this scenario you should configure your CA following the steps in scenario A, step I.
Scenario C involves the following tasks:
On the server, log on locally as root and start the Web-based System Manager. The security configuration applications of the Web-based System Manager are not accessible if you are not logged in as root or if you are running the Web-based System Manager in remote application or applet mode.
Open the "System" container and find the security configuration object, "Server Security".
On the object menu for "Server Security" select "Generate Servers' Private Keys and Certificate Requests...". Fill in the following information:
List of servers
Add the name of this Web-based System Manager server to the list.
The server name is shown in the first text-field by default.
Click the "Add to List" button to add it to the list.
Organization name
Enter a descriptive name that identifies your company
or your organization.
ISO country code
Enter your 2 character ISO country code or select it
from the list.
Location for private key files and certificate requests
Enter the directory where you want the server private
key file and certificate request written. In Step II,
you will need to transfer the certificate request file to
your CA for signing. In Step III, you will need to transfer
the signed certificate from the CA back to this directory.
Length in bits of server keys
Select a key length (this field only appears if you have
the sysmgt.websm.security-us fileset installed).
Encrypt the server private key files
This dialog creates a private key file for the server that
you specified. The private key file contains the private key
of the server. If someone steals this key he gains the power
of pretending to be that server. Thus this file should be
always kept protected. You can protect the private key file
by encrypting it. If you select this option, you will be
prompted for a password. Remember this password. You will
be asked for it when you import the signed certificate and
when you install the private key ring on this server.
When you click OK, a private key file (S.privk) and a certificate request (S.certreq) is created for this server (S).
You can perform this task from the command line with the smgenkeycr command.
In this step you need to transfer the certificate request file to your CA. The certificate request does not contain secret data, however, the integrity and authenticity during transfer must be insured.
Transfer a copy of the certificate request file from the server to a directory on your the CA machine. To save time you can transfer the certificate requests from all of your servers and have all of them signed by the CA in one step.
Log on to your CA machine locally as root and start the Web-based System Manager. The security configuration applications of the Web-based System Manager are not accessible if you are not logged in as root or if you are running the Web-based System Manager in remote application or applet mode.
Open the "System" container and find the security configuration object, "Certificate Authority".
On the object menu for "Certificate Authority" select "Sign Certificates...". Fill in the following information:
Directory for certificate requests
Enter the directory containing the certificate request(s).
Then click the "Update List" button. The certificate
request will appear in the list box.
Select certificate requests to sign
Click on your server's certificate request(s) in the list box.
Certificate Expiration Date
After the expiration date you will need to repeat this
process to generate a new private key ring file for your
server. You can change this date or accept the default date.
When you click OK, a certificate file (S.cert) is created for each server (S) that you selected. The certificate is written to the directory containing the certificate request.
You can perform this task from the command line with the smsigncert command.
In this step you need to transfer the certificate from the CA back to the server. Copy it to the directory containing the certificate request and server private key file that you previously created in step I.
Then, on the server, from the object menu for "Server Security", select "Import Signed Certificates...".
Fill in the following information:Directory for certificates and private keys
Enter the directory containing the signed certificate
and server private key file. Then click the "Update List"
button. The server will appear in the list box.
Select one or more servers from the list
Click on your server's name in the list box.
When you click OK, if the server private key file was encrypted in step I, you will be prompted for the password. Then, your server's certificate (S.cert) is imported in to the private key file (S.privk) and the private key ring file (S.privkr) is created in the directory containing the certificate request and private key file.
You can perform this task from the command line with the smimpservercert command.
On the object menu for "Server Security", select "Install Private Key Ring...". Select the "Directory" button and enter the directory containing the server's private key ring file. If the key file was encrypted, you will be asked for the password. Then, the server's private key is installed in /usr/websm/security/SM.privkr.
You can perform this task from the command line with the sminstkey command.
A copy of SMpubkr.class from the directory you specified in step I must be placed in the /usr/websm/codebase directory of your Web-based System Manager servers and AIX clients.
Note: The content of this file is not secret. However, placing it on a client machine specifies which CA the client trusts. Thus access to this file on the client machine should be limited. In applet mode, the client can trust the server to send over this file along with the applet itself - provided the HTTPS protocol is used.
In this step you will need to provide the the full TCP/IP names of all of your Web-based System Manager servers. You can enter them in the dialog one at a time or you can provide a file containing a list of your servers, one per line.
On a server, log on locally as root and start the Web-based System Manager. The security configuration applications of the Web-based System Manager are not accessible if you are not logged in as root or if you are running the Web-based System Manager in remote application or applet mode.
Open the "System" container and find the security configuration object, "Server Security".
On the object menu for "Server Security" select "Generate Servers' Private Keys and Certificate Requests...". Fill in the following information:
List of servers
Add the names of your Web-based System Manager servers
to the list. You can enter them in the dialog one at
a time or you can provide a file containing a list of your
servers, one per line. To get the server names from the file,
enter the file name in the "File containing list of servers"
entry field and click the "Browse file" button. The "Browse
Server List File dialog" will allow to select some or all of
the servers in the list.
Organization name
Enter a descriptive name that identifies your company
or your organization.
ISO country code
Enter your 2 character ISO country code or select it
from the list.
Location for private key files and certificate requests
Enter the directory where you want the server private
key files and certificate requests written. In Step II,
you will need to transfer the certificate request files to
the CA for signing. In Step III, you will
need to transfer the signed certificates from the CA
back to this directory.
Length in bits of server keys
Select a key length (this field only appears if you have
the sysmgt.websm.security-us fileset installed).
Encrypt the server private key files
This dialog creates a private key file for each
server that you specified. Each private key file
contains the private key of a server. If someone steals
this key he gains the power of pretending to be that server.
Thus this file should be always kept protected.
You can protect the private key ring files by encrypting
them. If you select this option, you will be prompted for
a password. Remember this password. You will be asked for
it when you import the signed certificates and when you
install the private key rings on the servers.
When you click OK, a private key file (S.privk) and a certificate request (S.certreq) is created for each server, (S) that you specified.
You can perform this task from the command line with the smgenkeycr command.
In this step you need to transfer the certificate request files to the CA. The certificate requests do not contain secret data, however, the integrity and authenticity during transfer must be insured.
Transfer a copy of the certificate request files from the server to a directory on the CA machine.
Follow the instructions of your CA to generate the signed certificates out of the certificate requests. The next step will be easier if the name of the certificate file of server S is S.cert.
In this step you need to transfer the certificates from the CA back to the server. Copy them to the directory containing the certificate requests and server private key files that you created in step I. This step requires that the certificate file of a server S be named S.cert.
Then, on the server, from the object menu for "Server Security", select "Import Signed Certificates...".
Fill in the following information:Directory for certificates and private keys
Enter the directory containing the signed certificates
and server private key files. Then click the "Update List"
button. The list of servers for which there is a signed
certificate and a private key file will appear in the
list box.
Select one or more servers from the list
To select individual servers, click on them in the list box.
To select all of the listed servers, click the "Select All"
button.
When you click OK, if the server private key files were encrypted in step I, you will be prompted for the password. Then, for each server (S) that you selected, the certificate (S.cert) is imported in to the private key file (S.privk) and the private key ring file (S.privkr) is created.
You can perform this task from the command line with the smimpservercert command.
Each server's private key ring file must be installed on the server.
You can move the files to their targets in any secure way. We'll describe here two ways - shared directory and diskette TAR:
Place all of the key ring files on a shared directory (e.g. NFS, DFS) accessible to each server.
Note: For this method you should have chosen to encrypt the server private key ring files on the Generate Servers Private Key Ring Files dialog, since the files will be transferred in the clear. It is also recommended to restrict the access rights to the shared directory to the administrator.
Generate a diskette TAR containing all of the server private key ring files. The TAR archive should contain just the file names without the paths. To do this, change directories to the directory containing the server private key ring files and run the command tar -cvf /dev/fd0 *.privkr.
Next you will need to install the server private key rings on each server. Log on to each server as root, start the Web-based System Manager and open the System container. On the object menu for "Server Security" select "Install Private Key Ring...". Select the source for the server private key ring files. If using a diskette TAR, insert the diskette before clicking OK. Now go ahead and click on OK. If the key ring files are encrypted, you will be asked for the password. The servers private key is installed in /usr/websm/security/SM.privkr. Repeat this procedure on each server.
You can perform this task from the command line with the sminstkey command.
Receive the CA (self signed) certificate of your CA (see the documentation for your CA). Copy it to a directory on the server you are working on.
Then, on the server, from the object menu for "Server Security", select "Import CA Certificate...".
Fill in the following information:Directory containing public key ring file
Enter a directory for the public key ring file,
SMpubkr.class. This file will need to be
distributed to all of your servers and clients.
Full path name of CA Certificate file
Enter the directory containing the self signed certificate
of your CA.
When you click OK, if the public key ring file SMpubkr.class will be written to the directory you specified.
You can perform this task from the command line with the smimpcacert command.
A copy of SMpubkr.class must be placed in the /usr/websm/codebase directory of all Web-based System Manager servers and clients.
Note: The content of this file is not secret. However, placing it on a client machine specifies which CA the client trusts. Thus access to this file on the client machine should be limited. In applet mode, the client can trust the server to send over this file along with the applet itself - provided the HTTPS protocol is used.
The SMGate daemon installed with Web-based System Manager Security allows you to run the Web-based System Manager in secure applet mode without having to configure your web server for security on each system to be managed. SMGate serves as an SSL gateway between the client browser and the local web server.
To use SMGate, you will need to receive the Certificate Authoritie's certificate into your client browsers.
Log on to the CA machine in local mode as root. Start the Web-based System Manager and open the System container. On the object menu for "Certificate Authority" select "Export Certificate...". The "Export Certificate Authority's Certificate" dialog will be displayed. Enter the full pathname where you want the certificate written, and click OK. Alternatively, from the command line type:If you are not using the Web-based System Manager internal certificate authority then use your certificate authority's procedures for obtaining a copy of its certificate.
/usr/websm/bin/wsmserver -smexpcacert
Your browsers are now set up to connect to your servers through SMGate. For enabling the SMGate daemon, see "Enabling SMGate", for running through SMGate see "Running Web-based System Manager Security: Applet Mode".
To view CA properties open the system container and find the security configuration object "Certificate Authority". On the object menu for "Certificate Authority", select "Properties". The dialog provides read-only information for the CA.
Detailed information on all operations executed by the CA (e.g., key ring generation, certificate signing) can be found in the CA log file /usr/websm/security/SMCa.log.
You can perform this task from the command line with the smcaprop command.
You can perform this task from the command line with the smserverprop command.
You can enable security so that the managed system will accept secure or unsecure connections by running the command: wsmserver -ssloptional. In this mode, the user at the client can select an option on the Web-based System Manager logon dialog to specify a secure or unsecure connection.
You can enable security so that the managed system will only accept secure connections by running the command /usr/websm/bin/wsmserver -sslalways.
To enable SMGate, enter the command: /usr/websm/bin/wsmserver -enablehttps. This starts SMGate and adds an entry to the /etc/inittab file so that it is automatically activated when the system is restarted. The default port for SMGate is 9092. You can look in the /etc/services file to make sure this port is not being used by another service. You can configure SMGate to use a different port with the command: /usr/websm/bin/wsmserver -enablehttps <port> where <port> is the port number you want it to use.
If you change the server's security configuration you must disable SMGate and re-enable it. The command for disabling SMGate is /usr/websm/bin/wsmserver -disablehttps.
To configure the browser for working through SMGate, see section "Configuring for SMGate".
If the machine to be managed is configured to allow secure connections only (see Enabling Web-based System Manager Security), then the client must have the sysmgt.websm.security fileset installed and must have a copy of the public key ring file, SMpubkr.class in directory /usr/websm/codebase. In this mode the Web-based System Manager logon dialog will have a checkbox indicating that security is required.
If the machine to be managed is configured to allow secure or unsecure connections (see Enabling Web-based System Manager Security) and the client has a copy of the public key ring file, SMpubkr.class in the /usr/websm/codebase directory, then the Web-based System Manager logon dialog will have a checkbox that allows the client user to specify a secure or unsecure connection. If the client machine does not have the SMpubkr.class file, only a unsecure connection can be established.
Security when running in application mode is indicated by a "secure connection" message on the status line at the bottom of the Web-based System Manager containers.
One option is to use the SSL capability of the web server on the managed machine. For this option, the web server must be configured for security. Follow the instructions provided with your web server. Then you can access the Web-based System Manager on the managed machine with the URL "https://<hostname>/wsm.html". (where <hostname> is the name of the remote machine you want to manage). In this option, the Web-based System Manager applet and public key ring SMpubkr.class are transferred securely from the web server on the managed machine to the client.
Another option is to use the SMGate daemon. SMGate runs on the managed AIX machine and serves as an SSL gateway between the client browser and the local web server. SMGate responds to the HTTPS request of the client browser, and creates an SSL connection with it using the private key and certificate of the Web-based System Manager server. Inside the managed machine, SMGate creates an unsecure connection to the local web server. In this option, the Web-based System Manager applet and public key ring SMpubkr.class are transferred securely from SMGate on the managed machine to the browser client and communications between the managed machine and client are over SSL. When you are using a SMGate, you can access the Web-based System Manager on the managed machine with the URL "https://<hostname>:9092/wsm.html". (where <hostname> is the name of the remote machine you want to manage). 9092 is the default port number for SMGate. If you enabled SMGate with a different port number, then specify that number.
There are two security indicators to look for when running in applet mode, the browser's HTTPS indication, and the "secure connection" message on the status line at the bottom of the Web-based System Manager containers. If either indicator is missing, the connection is not completely secure.
| Problem | Action |
|---|---|
| No security icons in the System container. | Make sure you're logged in as root, and operating Web-based System Manager on the local machine. |
| When trying to use the CA for generating key rings or signing certificate requests, a message CA access is locked (SMCa.lock) is issued. | If you are sure that no other administrator is currently using the CA, remove the CA lock file /usr/websm/security/SMCa.lock. |
| In SMGate configuration, the browser doesn't recognize the CA certificate file as a CA certificate. | Check in the web server documentation that the MIME type being sent by the web server for the certificate file you placed is indeed application/x-x509-ca-cert. |
| In running through SMGate, the browser issues an error message about invalid signature | It could be that the server is certified by a new CA with the same name as an old CA and that the browser has the CA certificate of the old CA. Delete the old CA certificate in the browser and follow the SMGate configuration section to receive the new certificate. |
| Secure remote activation of Web-based System Manager fails. | First, verify that non-secure remote activation works (you might
need to change the server's setting for that, if it doesn't permit
non-secure connections.
Certificate matching and expiration:
|