To do so, enter the following commands as root :. This allows stunnel to create the PID file. If your system is using firewall settings that disallow access to the new port, change them accordingly. See Section 5. When you have created the configuration file and the chroot directory, and when you are sure that the specified port is accessible, you are ready to start using stunnel.
Starting, Stopping, and Restarting stunnel. To start stunnel , enter the following command as root :. To terminate stunnel , kill the process by running the following command as root :. If you edit the configuration file while stunnel is running, terminate stunnel and start it again for your changes to take effect.
In order for communication to be secured, it must be:. A certificate is an electronic file that can contain both a public and a private key. The values in the certificate are used to encrypt and sign the transmitted data by Stunnel and are used to decrypt and verify the data after it arrives at the server. Alma certificates are associated with an integration profile. The certificate uniquely identifies both the institution and the integration profile.
Refer to the specific integration you want to set up for details of the integration profile and the certificate. In certain situations, you must create multiple connection definitions in the stunnel.
If you receive multiple client certificates from your Alma implementation engineer, add each one with a different name to the Stunnel installation directory, Then copy the entire [Integration Profile 1] section and edit the appropriate values, including the certificate file name and accept port.
For example, you can add a second [Integration Profile 2] using client2. If Stunnel is operating correctly, the command prompt clears and you connect to Stunnel. For example:. SSL also added the capability to authenticate clients and servers alike with X.
Besides its obvious relevance to web security, OpenSSL has led to the creation of Stunnel, one of the most versatile and useful security tools in the open source repertoire. Stunnel makes it possible to encrypt connections involving virtually any single-port TCP service in SSL tunnels, without any modifications to the service itself. By "single-port TCP service," I mean a service that listens for connections on a single TCP port without subsequently using additional ports for other functions.
FTP, which listens on TCP 21 for data connections but uses connections to additional random ports for data transfers, is not such a service. Admittedly, this may be due to superstition, but if so, it's superstition fueled by history. Stunnel relies on OpenSSL for all its cryptographic functions.
Your distribution's base OpenSSL package will probably suffice, but if you have trouble building Stunnel, try installing the openssl-devel package or your distribution's equivalent. If you plan to use Stunnel with client-side certificates i. To compile OpenSSL, uncompress and untar the source tarball, change your working directory to the source's root directory, and run the config script.
I recommend passing three arguments to this script:. For example, using my recommended paths, the configuration command would be as follows:. If config runs without returning errors, run make , followed optionally by make test and then by make install.
You are now ready to create a local Certificate Authority and start generating certificates. Stunnel uses two types of certificates: server certificates and client certificates. Any time Stunnel runs in daemon mode i. Binary distributions of Stunnel often include a pregenerated stunnel.
You'll therefore need to generate at least one server certificate, and if you wish to use client certificates, you'll need to generate them too. Either way, you'll need a Certificate Authority CA. Perhaps you think of CAs strictly as commercial entities like VeriSign and Thawte, who create and sign web-server certificates for a fee; indeed, x. When users or their web browsers need to verify the authenticity of a web server's certificate, a "neutral third party" like a commercial CA is often necessary.
However, it's far more likely that any certificate verification you do with Stunnel will involve the server-authenticating clients, not the other way around.
This threat model doesn't really need a third-party CA: in the scenarios in which you'd most likely deploy Stunnel, the server is at greater risk from unauthorized users than users are from a phony server. To the extent that users do need to be concerned with server authentication, a signature from your organization's CA rather than from a neutral third party is probably sufficient. These are some of the situations in which it makes sense to run your own Certificate Authority.
If all this seems a bit confusing, Figure shows how clients, servers, and CAs in SSL relationships use certificates. Figure illustrates several important aspects of the SSL and of public-key infrastructures in general. First, you can see the distinction between public certificates and private keys. In public-key cryptography, each party has two key: one public and one private.
SSL is based on public-key cryptography; in SSL's parlance, a signed public key is called a certificate, and a private key is simply called a key. If you're completely new to public-key cryptography, see the Section 4. As Figure shows, certificates are freely shared? Keys, on the other hand, are not: each key is held only by its owner and must be carefully protected for its corresponding certificate to have meaning as a unique and verifiable credential.
Another important point shown in Figure is that Certificate Authorities do not directly participate in SSL transactions. So important is the trustworthiness of these signatures, that the less contact your CA has with other networked systems, the better. It's not only possible but desirable for a CA to be disconnected from the network altogether, accepting new signing requests and exporting new signatures manually?
This minimizes the chance of your CA's signing key being copied and misused: the moment a CA's signing key is compromised, all certificates signed by it become untrustworthy.
For this reason, your main Intranet fileserver is a terrible place to host a CA; any publicly accessible server is absolutely out of the question. When a host "verifies a certificate," it does so using a locally stored copy of the CA's "CA certificate," which, like any certificate, is not sensitive in and of itself. It is important, however, that any certificate copied from one host to another is done over a secure channel to prevent tampering.
Also, given the importance and sensitivity of CA activities, you should be logged in as root when performing CA functions, and all CA files and directories should be owned by root and set to mode or One of them, CA , can be used to automatically set up a CA directory hierarchy complete with index files and a CA certificate and key.
Before you use it, however, you should tweak both it and the file openssl. First, in CA. One noteworthy variable is DAYS , which sets the default lifetime of new certificates. I usually leave this to its default value of -days , but your needs may differ.
By default, this is set to. The leading. There's nothing to stop you from making this an absolute path, though: you'll just need to change the script if you want to run it again to create another CA; otherwise, you'll copy over older CAs. Multiple CAs can be created on the same host, each with its own directory tree. In openssl. These are less important? This setting determines the strength of your certificate's key, which is used to sign other certificates, and in the case of SSL clients and servers but not of CAs , to negotiate SSL session keys and authenticate SSL sessions.
Recent advances in the factoring of large numbers have made a safer choice, though computationally expensive but only during certificate actions such as generating, signing, and verifying signatures, and during SSL session startup? The CA script reads openssl. Now, change your working directory to the one in which you wish to locate your CA hierarchy.
From this directory, run one of the following commands:. The script will prompt you for an existing CA certificate to use Example ; simply press Return to generate a new one. You'll next be prompted for a passphrase for your new CA key. This passphrase is extremely important: anyone who knows this and has access to your CA key can sign certificates that are verifiably valid for your domain.
Choose as long and complex a passphrase as is feasible for you. Whitespace and punctuation marks are allowed. By default, the CA. Now you're ready to create and sign your own certificates. In practice, however, the CA is the logical place to do this, since you won't have to worry about the integrity of certificates created elsewhere and transmitted over potentially untrustworthy bandwidth.
In other words, it's a lot easier to feel good about signing a locally generated certificate than about signing one that was emailed to the CA over the Internet. For Stunnel use, you'll need certificates for each host that will act as a server. If you plan to use SSL client-certificate authentication, you'll also need a certificate for each client system. Stunnel supports two types of client-certificate authentication: you can restrict connections to clients with certificates signed by a trusted CA, or you can allow only certificates of which the server has a local copy.
Either type of authentication uses the same type of client certificate. There's usually no difference between server certificates and client certificates.
The exception is that server certificates must have unencrypted i. If a client certificate's key is encrypted with a strong passphrase, the risk of that key's being copied or stolen is mitigated to a modest degree. On the other hand, if you think the application you'll be tunneling through Stunnel has adequate authentication controls of its own, or if the client Stunnel process will be used by an automated process, unencrypted client keys may be justified.
Just remember that any time you create client certificates without passphrases, their usefulness in authenticating users is practically nil. Before you start generating host certificates, copy the openssl. At the very least, I recommend you set the variable dir in this copy of openssl. Now let's generate a certificate. We'll start with a server certificate for an Stunnel server named "elfiero":. Change your working directory to the CA directory you created earlier?
Create a new signing request which is actually a certificate and key with this command:. The -nodes flag specifies that the new certificate should be unencrypted.
Automated processes will be using it, so it isn't feasible to encrypt it with a password that must be entered every time it's used. The filenames passed to both -keyout and -out are both arbitrary: you can name them whatever you like. Another flag you can include is -newkey rsa: [bits] , where [bits] is the size of the new certificate's RSA key?
After you enter this command, you will be prompted to enter new values or accept default values for the certificate's "Distinguished Name" parameters Country Name , Locality Name , etc. Note that each certificate's Distinguished Name must be unique: if you try to create a certificate with all the DN parameters the same as those of a previous certificate created by your CA, the action will fail with an error. Again, you can call the output file specified by -out anything you want.
After entering this command, you'll be prompted for the CA key's passphrase, and after you enter this, you'll be presented with the new certificate's details and asked to verify your intention to sign it. If you skipped to this procedure from Section 7. Otherwise, proceed to Step 4. Open the new key e. This step isn't strictly necessary for recent versions of Stunnel, which isn't as fussy about certificate file formatting as it used to be, but I still add the blank line, since it's one less thing that can cause problems e.
Open the new signed certificate e. Add a blank line to the bottom of the file and save it. Again, the blank line may not be necessary, but it doesn't hurt. That's it! Creating certificates for Stunnel client systems, which again is optional, is no different than creating server certificates.
Omit the -nodes flag in Step 2 if you wish to password-protect your client certificate's key. Unfortunately, doing so buys you little security when using Stunnel. Although you'll need to enter the correct passphrase to start an Stunnel client daemon using a password-protected certificate, after the daemon starts, any local user on your client machine can use the resulting tunnel.
However, the owner module, which provides these options, is still experimental and must be enabled in a custom kernel build. Linux in a Nutshell by Siever et al O'Reilly includes documentation on Iptables in general and the owner match module specifically. In other SSL client-certificate scenarios e. In other words, when certificates will be used by human beings, especially by human beings logged on to shared systems, these should usually not be generated with OpenSSL's -nodes flag unless you have carefully considered the security ramifications and mitigated the risks associated with these client keys?
From an Stunnel server's perspective, the client certificate effectively authenticates the Stunnel client system and not the tunneled application's users per se. This is true of any server application that accepts connections involving either certificates with unprotected keys or shared client daemons.
0コメント