lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev FORCE_SSL_PROMPT:NO


From: Stef Caunter
Subject: Re: lynx-dev FORCE_SSL_PROMPT:NO
Date: Wed, 23 Jul 2003 23:45:05 -0400 (EDT)

Attached, and sent below, is README.sslcerts

--Stef

On Wed, 23 Jul 2003, Henry Nelson wrote:

> > Is there somewhere that this could be documented? I don't
> > mind doing a step by step write up of the procedure
> > (download cert, convert to pem format, rehash, set
>
> The first place I would look would be "docs/README.ssl".  That file
> seems to be mostly obsolete and not a lot of help.  If you could write
> a replacement, many people would be sure to benefit.
>
> __Henry
>
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
>


        Lynx SSL support for certificates - README.sslcerts file

BACKGROUND:

The original README.ssl document for lynx stated:

        Note that the server... may not have a valid certificate. Lynx will not
        complain, as it does not yet support certificates...

Such lack of support is no longer the case.  Lynx now features excellent
certificate management through the openssl project.  There is almost no
online documentation available regarding how to use openssl's certificate
management with other programs, so this will accompany lynx and hopefully
encourage good practical security for unix clients.

Lynx relies on openssl to not only encrypt connections over https, but also to
determine whether it should even accept a certificate and establish a secure
connection with a remote host. Because of this reliance upon openssl by lynx,
most of this tutorial deals with how to use openssl to "install" both
commercial CA cert bundles as well as self-signed certs from trusted sources
and most importantly, how to get them recognized by lynx.

While lynx on a correctly set up system will transparently accept valid
certificates, not all systems enjoy such functionality. Further, as noted
above, older versions of lynx do not perform any validity check on a
certificate.

There is also the common case of wanting to trust, use and install a
self-signed certificate from a known source and have it be trusted by the
browser.

Briefly, the procedure will involve confirming the default system location for
certificates, setting and exporting the environment variable SSL_CERT_DIR,
and hashing the certificates found in that directory using an openssl utility
to enable recognition.

THE CURRENT SITUATION:

Prior to lynx2.8.5dev9, lynx did not check at all for certificate validity.

Since lynx2.8.5.dev9, lynx has reported this error:

SSL error:unable to get local issuer certificate-Continue? (y)

whenever an https connection was initiated and the certificate could not be
found for whatever reason, by openssl, and therefore lynx.

This checking for a certificate is an enhancement to security, but rather
tediously generates errors at each https browser request.

The ability to turn off reporting of this error to the user was added to
lynx2.8.5dev16 as the FORCE_SSL_PROMPT setting in lynx.cfg as noted in the
CHANGELOG:

        This lets the user decide whether to ignore prompting for questionable
        aspects of an SSL connection.

While this is a convenient setting to employ when using lynx to script
https -dumps, it by definition ignores the issue of certificate validity
altogether. Those concerned with proper certificate management and
the maintenance of a store of updated CA certificates will be uncomfortable
with this relaxed security setting.

PROCEDURES:

It is assumed that openssl has been installed correctly, that SSL_CERT_DIR is
/usr/local/ssl/certs, and that lynx has been compiled --with-ssl. If the
default location for certs on your system is different you will have to
substitute that location for /usr/local/ssl/certs in the following instructions.

The source for openssl will be required in order to access the c_rehash utility
and the CA cert bundle.

If you simply need to have commercially provided certificates trusted by lynx,
you can skip down a few lines to the INSTALLING OR UPDATING THE CA BUNDLE
section.

INSTALL A SELF-SIGNED CERTIFICATE:

When you would like to trust a self-signed (non-commercial) certificate you will
need to get hold of the actual file. If it's a cert local to your network you
can ask the sysadmin to make it available for download as a link on a webpage.

If such file is not human-readable it's probably DER formatted and will need to
be converted to PEM format to allow openssl to use it.

To convert DER formatted certificates into something openssl can deal with:

Save the cert as site_name.crt in a directory. In that directory, type:

openssl x509 -inform DER -in site_name.crt -outform PEM -out site_name.pem

The file will now be in an acceptable format to openssl, PEM encoded. However,
openssl, and by extension lynx, will not know about it until that cert is
present in a file named after the hash value of that cert, in the default
/usr/local/ssl/certs.

So the next thing to do is to hash the cert using c_rehash in the default
location for your system (SSL_CERT_DIR, the oft-referred to
/usr/local/ssl/certs), and to set the environment variable so that openssl,
and lynx, can find the certs.

INSTALLING OR UPDATING THE CA BUNDLE:

Now would be a good time to check to see if you have the bundle of CA certs
in your /usr/local/ssl/certs, or to update them. Openssl and mod_ssl ship
with them.  They are in the certs directory of the openssl source tree.
Copy them to /usr/local/ssl/certs.

We now have all of the certs we wish to trust in our certs directory.
Run the perl script c_rehash, which ships with the openssl source, and is
located in the tools directory of the openssl source tree.

As root, run:

./c_rehash

This is a perl script that runs openssl commands which creates the files
named after the hash values of the certs in the default directory for certs.
The output looks like this:

Doing /usr/local/ssl/certs
vsignss.pem => f73e89fd.0
vsign3.pem => 7651b327.0
...more output
<snip>

All pem encoded certs in /usr/local/ssl/certs will now be recognized as long
as we perform the last step.

SETTING AND EXPORTING THE ENVIRONMENT VARIABLE SSL_CERT_DIR:

Almost done! The last thing we _have_ to do is set the environment variable
SSL_CERT_DIR in our shell initialization .profile or .*shrc, or /etc/profile,
like so:

SSL_CERT_DIR=/usr/local/ssl/certs
export SSL_CERT_DIR

This environment variable _must_ be set, and it must be exported!

Make sure you have set FORCE_SSL_PROMPT set to PROMPT in lynx.cfg like so:

FORCE_SSL_PROMPT:PROMPT

You will now connect without error to https servers with trusted certs, but
will still get this error for untrusted certs:

SSL error:self signed certificate-Continue? (y)

A quick check confirms that these procedures have the same effect with ssl
errors in the pine program.

--Stef Caunter <address@hidden>
Mohawk College Department of Computer Science
Hamilton Ontario Canada

Attachment: README.sslcerts
Description: new README for certs/ssl


reply via email to

[Prev in Thread] Current Thread [Next in Thread]