The ServerName is established in the httpd.conf file.
An SSL Certificate tries to compare its Common Name with the ServerName. If they don't match, there's a problem.

I created a self-signed certificate using the openssl utility where I must have originally mistyped the ServerName for the Common Name. This was apparent since the names didn't match. So I had to repeat the process but with the correct info.

The first certificate I created on June 26th. I've deleted the files server.key and server.crt from their respective directories and replaced them with newly created files with the correct information in them. However, when I open my browser and get the dialog box that warns about the certificate and I check the date it still reads June 26th.
This is now the 29th. of June so the cerificate should reflect that since the latest one I created was today. How is it the server is retaining this older certificate in memory? Why isn't it reading the latest certificate?

Alan

If serverside result of "cat /directory/certificate.pem|openssl x509 -noout -dates" shows the right dates then check if the server had the chance to reread info (kill -HUP). If it did then it could be a clientside issue with a cached cert.

I found the problem! Others might learn from what I discovered. Actually, an individual from another newsgroup forum on Linux suggested looking for an Include directive in the httpd.conf file.
I looked and there was. It pointed to an ssl.conf file that is specifically configured to include commands for setting up a virtual host listening on port 443 and sets the SSLCertificateFile directive and others to a directory where a default.crt file was being stored. The default.crt was a copy of the original server.crt file I had created.

Needless to say, I wound up editing the ssl.conf file to point the the proper files in the appropriate directories.

Thanks for your patients and suggestions,

Alan