SSL設定の手引き

The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 4, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 4 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references.

以下の記述ではTomcat4をインストールしたディレクトリを参照し、 ほとんどの相対的なパスが決定されている基本のディレクトリであるために 変数名$CATALINA_HOMEを使います。 しかし、もしCATALINA_BASEディレクトリをセットして複数の例のために Tomcat4に設定したならば、これらの参照のうちのそれぞれのための $CATALINA_HOMEの代わりに$CATALINA_BASEを使うでしょう。

To install and configure SSL support on Tomcat 4, you need to follow these simple steps. For more information, read the rest of this HOW-TO.

Tomcat4でのSSLサポートをインストールし、設定するために、 これらの簡単なステップに行う必要があります。 詳細については、この手引きを読んでください。

1. Download JSSE 1.0.2 (or later) from http://java.sun.com/products/jsse/ and either make it an installed extension on the system, or else set an environment variable JSSE_HOME that points at the directory into which you installed JSSE.
それからhttp://java.sun.com/products/jsse/より JSSE 1.0.2（もしくはそれ以降）をダウンロードしてください。 そしてシステムの拡張とするか、JSSEをインストールしたディレクトリを指し示す JSSE_HOME環境変数を設定してください。


2. Create a certificate keystore by executing the following command:

   	keytool -genkey -alias tomcat -keyalg RSA

   and specify a password value of "changeit".



3. 以下のコマンドを実行することによって認証のkeystoreを生成してください。

   	keytool -genkey -alias tomcat -keyalg RSA

   and specify a password value of "changeit". そして"changeit"の値のパスワードを指定してください。



4. Uncomment the "SSL HTTP/1.1 Connector" entry in $CATALINA_HOME/conf/server.xml and tweak as necessary.



5. $CATALINA_HOME/conf/server.xmlに記述されている"SSL HTTP/1.1 Connector"エントリのコメント化を外し、必要に応じて編集してください。

SSL, or Secure Socket Layer, is a technology which allows web browsers and web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.

SSL、Secure Socket Layer--はWebブラウザとWebサーバーに安全な接続を通じて通信を行う技術です。これは片側から送信された（通信を通じての）データが暗号化されて転送され、もう片方では非暗号化を処理する前にすることを意味します。これは２方向の処理であり、サーバとブラウザの両方がすべての通信交換において送信する前に暗号化を行うことを意味します。

Another important aspect of the SSL protocol is Authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a "Certificate", as proof the site is who and what it claims to be. In certain cases, the server may also request a Certificate from your web browser, asking for proof that you are who you claim to be. This is known as "Client Authentication," although in practice this is used more for business-to-business (B2B) transactions than with individual users. Most SSL-enabled web servers do not request Client Authentication.

SSLプロトコルにおけるほかの重要な仕様とは証明です。これはWebサーバを通じての安全な接続にての最初の試みの間、サーバはブラウザに"認証"のフォームの中の証明書で設定されますをサイトが誰でありそうである主張である証拠として提供することを意味します。 このような場合、サーバは同じくWebブラウザからの証明を要求します、あなたがであるかの確証性を尋ねます。 これは"クライアントの証明"として知られ、実際の場ではではこれは個人ユーザよりもB2Bトランザクションでもっと使われることでもちいられます。 多くのSSLを使用することができるWebサーバはクライアントの認証を要求しません。

It is important to note that configuring Tomcat to take advantage of secure sockets is usually only necessary when running it as a stand-alone web server. When running Tomcat primarily as a Servlet/JSP container behind another web server, such as Apache or Microsoft IIS, it is usually necessary to configure the primary web server to handle the SSL connections from users. Typically, this server will negotiate all SSL-related functionality, then pass on any requests destined for the Tomcat container only after decrypting those requests. Likewise, Tomcat will return cleartext responses, that will be encrypted before being returned to the user's browser. In this environment, Tomcat knows that communications between the primary web server and the client are taking place over a secure connection (because your application needs to be able to ask about this), but it does not participate in the encryption or decryption itself.

Tomcatを設定することで安全なソケットの優位性をとることは 通常はスタンドアロンWebサーバとして運用するときにだけ重要で あることを記することは重要です。 他のApacheやマイクロソフトIISのようなWebサーバの背後に Servlet/JSPコンテナとしてTomcatをプライマリに稼動させている とき、プライマリのWebサーバーがユーザーからのSSL接続をする ように設定することが重要です。 一般に、このサーバーはすべてのSSL関連の機能の交渉をさせて、そして、それらのリクエストを非暗号化する後にだけTomcatコンテナに向けられたどのような要求でも通過します。 同様に、Tomcatはcleartext反応を返しますが、それはユーザーのブラウザに返される前に暗号化されます。 この環境では、 Tomcatは、安全な接続（アプリケーションが、 これについて尋ねることができる必要があることによる）の上で 主要なウェブサーバーとクライアントの間の通信が起こっていると 知っているけれども、それは暗号化または暗号解読自身には 関与しません。

In order to implement SSL, a web server must have an associated Certificate for each external interface (IP address) that accepts secure connections. The theory behind this design is that a server should provide some kind of reasonable assurance that its owner is who you think it is, particularly before receiving any sensitive information. While a broader explanation of Certificates is beyond the scope of this document, think of a Certificate as a "digital driver's license" for an Internet address. It states what company the site is associated with, along with some basic contact information about the site owner or administrator.

SSLの手段を与えるにあたり、安全な接続を受け入れるそれぞれの外部インターフェース（IPアドレス）に 結びつく証明が、1つのWebサーバに必要です。 この設計におけるこの 定理と特にさまざまな場面で 影響を及ぼしやすい情報を受け取る前にはサーバは それが考えられる所有者のものであることを道理にかなった 保証を供給すべきです。 各々の証明のの広大な説明がこのドキュメントのスコープの範ちゅうを超えて存在している間、説明をインターネット所在地のための「デジタル運転免許証」として捉えてください。 これはそのサイトがサイトの所有者もしくは管理者についての基礎的な連絡情報とともに、どんな人たちによって設定されているのか述べています。

この「運転免許証」は暗号の使用者によって署名が行われますが、これが行われることで書名の偽造が大変に難しくなります。eコマースやビジネスの取引などのようにアイデンティティの証明が重要なことにおいては、代表的には良く知られている"VeriSign"や"Thawte"のような証明機関（CA）によって証明は発行されます。

Certificate Authority (CA) such as VeriSign or Thawte. Such certificates can be electronically verified -- in effect, the Certificate Authority will vouch for the authenticity of the certificates that it grants, so you can believe that that Certificate is valid if you trust the Certificate Authority that granted it.

"VeriSign"や"Thawte"などの証明書権限（CA）。 そのような証明書は電子的に確認できます??実際には、証明書権限は、それが与えるという証明書の確実性を保証します。従って、もしそれを与えた証明書権限を信頼するならば、その証明書が有効であると硬く信頼することができるでしょう。

In many cases, however, authentication is not really a concern. An administrator may simply want to ensure that the data being transmitted and received by the server is private and cannot be snooped by anyone who may be eavesdropping on the connection. Fortunately, Java provides a relatively simple command-line tool, called keytool, which can easily create a "self-signed" Certificate. Self-signed Certificates are simply user generated Certificates which have not been officially registered with any well-known CA, and are therefore not really guaranteed to be authentic at all. Again, this may or may not even be important, depending on your needs.

しかし、多くの事例において確証がまったく証明にならないことがあります。管理者はサーバにより送信および受信されるデータは内密なものであり、接続状況において盗み聞きをするすべての人からのぞきまわられなどしないように確立することを望んでいるのです。 幸運なことに、「自身による証明がなされた」証明を作ることができる keytool という比較的シンプルなコマンドライン・ツールを Java は提供しています。 自身による証明がされた証明はよく知られた証明期間による公式に署名がなされたものではなく、単にユーザによりつくりだされた証明なので、結局のところ確実である保証はありません。復唱しますが、このことは用途にゆだねられているので、重要であったりそうでなかったりします。

The first time a user attempts to access a secured page on your site, he or she is typically presented with a dialog containing the details of the certificate (such as the company and contact name), and asked if he or she wishes to accept the Certificate as valid and continue with the transaction. Some browsers will provide an option for permanently accepting a given Certificate as valid, in which case the user will not be bothered with a prompt each time they visit your site. Other browsers do not provide this option. Once approved by the user, a Certificate will be considered valid for at least the entire browser session.

ユーザが安全なサイトにはじめての訪問をするときには 一般的に（企業もしくは名称のような）証明の詳細を含んだダイアログが表示され、 証明が有効であると受け入れると同時にページの閲覧を 続けるかどうかたずねられます。 このサイトをユーザが再度訪れた際もたずねられることが ないように、いくつかのブラウザは与えられた証明を永久に 有効であるとするオプションを提供します。 他のブラウザではこのオプションはサポートされませんが 一度ユーザに認められたら、証明は最低でもブラウザを開いている間ずっと有効であるととらえます。

Also, while the SSL protocol was designed to be as efficient as securely possible, encryption/decryption is a computationally expensive process from a performance standpoint. It is not strictly necessary to run an entire web application over SSL, and indeed a developer can pick and choose which pages require a secure connection and which do not. For a reasonably busy site, it is customary to only run certain pages under SSL, namely those pages where sensitive information could possibly be exchanged. This would include things like login pages, personal information pages, and shopping cart checkouts, where credit card information could possibly be transmitted. Any page within an application can be requested over a secure socket by simply prefixing the addres with https: instead of http:. Any pages which absolutely require a secure connection should check the protocol type associated with the page request and take the appropriate action of https is not specified.

これは SSL でWebアプリケーション全体を稼動させることに ついては厳格に必要なことでもありません。 そしてもちろん、開発者はどのページが安全な接続状態を必要として いるのか、あるいはそうでないのか拾い上げて、選ぶことができます。 ヒット率が高く稼働率の高いサイトでは、影響を与えやすい情報が 交換される必要があるページに限り、SSLを適用することが通例です ヒット率が高く稼働率の高いサイトでは、影響を与えやすい情報が交換される必要があるページに限り、SSLを適用することが通例です。 これらはログインのページ、個人情報のページ、ショッピングカーとの支払いなどクレジットカードの情報が送信される可能性があるページです。 Any pages which absolutely require a secure connection should check the protocol type associated with the page request and take the appropriate action of https is not specified.

アプリケーション内部ならどのページでもアドレスはhttp:からhttp:に書き換えれば安全なソケットで呼び出すことができます。 安全な接続形態が絶対に必要なページは関連のページが呼ばれる際のプロトコルの種別とhttpsが指定されないときの適切な挙動をチェックされるべきです。

Finally, using name-based virtual hosts on a secured connection can be problematic. This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must occur before the HTTP request is accessed. As a result, the request information containing the virtual host name cannot be determined prior to authentication, and it is therefore not possible to assign multiple certificates to a single IP address. If all virtual hosts on a single IP address need to authenticate against the same certificate, the addition of multiple virtual hosts should not interfere with normal SSL operations on the server. Be aware, however, that most client browsers will compare the server's domain name against the domain name listed in the certificate, if any (applicable primarily to official, CA-signed certificates). If the domain names do not match, these browsers will display a warning to the client user. In general, only address-based virtual hosts are commonly used with SSL in a production environment.

最終的にですが、安全な接続上の名前ベースの仮想ホストの 使用は問題をまねきやすいです。 これはSSLプロトコル自身の設計上の制限なのです。 クライアントブラウザがサーバの証明を受け付けるところで、 HTTPリクエストがアクセスされる前にSSLハンドシェークが行われなければなりません。 結果として、仮想ホスト名を含むリクエスト情報は承認以前には決定することができず、それゆえに複数の証明を１つのIPアドレスに指定することができません。 もし単一のIPアドレス上にある仮想ホストが同じ証明書に対して 認証を行う必要があるのであれば、複数の仮想ホストの付加による サーバーでの正常なSSLオペレーションは妨げられないでしょう。 しかし気づきます、ほとんどのクライアントブラウザは、 もしあれば証明書にリストされたドメイン名に対するサーバーの ドメイン名を比較します（第一に公式に適切なCA-サインされた証明書があるか）。 もしドメインネームがマッチしていないならば、 これらのブラウザはクライアントユーザーに警告を表示する でしょう。 一般に、アドレスベースのバーチャルであるだけのホストは 一般的に生産環境においてSSLによって使われます。

Download and Install JSSE JSSEのダウンロードとインストール

Download the Java Secure Socket Extensions (JSSE) package, version 1.0.2 or later, from http://java.sun.com/products/jsse/. If you built Tomcat from source, you have probably already downloaded this package. If you are running JDK 1.4 (currently in beta), these classes have been integrated directly into the JDK, so you can skip this entire step. http://java.sun.com/products/jsse/からヴァージョン1.0.2もしくはそれ以降のJava Secure Socket Extensions (JSSE) のパッケージをダウンロードしてください。 Tomcatをソースからビルドしたのであれば、すでにこのパッケージもダウンロードしていることでしょう。JDK1.4（現在はベータ版）を使用しているのであれば、これらのクラスはダイレクトにJDKに統合されているので、以下ののステップはすべて省略することができます After expanding the package, there are two ways to make it available to Tomcat (choose one or the other): パッケージを解凍した後、Tomcatをメイクするためには2つの方法があります（どちらかを選択してください） Make JSSE an installed extension by copying all three JAR files (jcert.jar, jnet.jar, and jsse.jar) into your $JAVA_HOME/jre/lib/ext directory. 以下の３つのすべてのJARコピーしてJSSEを 機能拡張インストールする。 (jcert.jar, jnet.jar, and jsse.jar) そして$JAVA_HOME/jre/lib/ext ライブラリに加えてください。 Create a new environment variable JSSE_HOME that contains the absolute path to the directory into which you unpacked the JSSE binary distribution. 新たにJSSEのバイナリ版を解凍したディレクトリへの絶対パスを含む環境変数JSSE_HOME that contains をつくる。

Prepare the Certificate Keystore 証明のためのkeystoreを準備する

Tomcat currently operates only on JKS format keystores. This is Java's standard "Java KeyStore" format, and is the format created by the keytool command-line utility. This tool is included in the JDK. Tomcatは現在のところJKSフォーマットのkeystore群によってのみ稼動します。これがJava標準の"Java KeyStore"フォーマットであり、このフォーマットはkeytoolコマンドラインユーティリティで生成されます。このツールはJDKに含まれています。 To import an existing certificate into a JKS keystore, please read the documentation (in your JDK documentation package) about keytool. すでに存在する証明をJKSフォーマットkeystoreに取り込むためには、keytool.に関するドキュメント（JDKに付属）を読んでください。 To create a new keystore from scratch, containing a single self-signed Certificate, execute the following from a terminal command line: 自分で自己の単一な証明のために新しいkeystoreをつくるには、 ターミナルで以下のコマンドを実行してください。 keytool -genkey -alias tomcat -keyalg RSA (The RSA algorithm should be preferred as a secure algorithm, and this also ensures general compatibility with other servers and components.) （このRSAアルゴリズムは安全性のアルゴリズムよりも優先されるべきであり、また、他のサーバとコンポーネントに対して標準の互換性を保証します。） This command will create a new file, in the home directory of the user under which you run it, named ".keystore". To specify a different location or filename, add the -keystore parameter, followed by the complete pathname to your keystore file, to the keytool command shown above. You will also need to reflect this new location in the server.xml configuration file, as described later. For example: keytool -genkey -alias tomcat -keyalg RSA \ -keystore /path/to/my/keystore このコマンドは".keystore"という名前でユーザが実行を行っているディレクトリに新しくファイルをつくります。他の場所や他のファイル名を特定するには、以下のkeytoolコマンドを実行してください。 新しい場所には後述するserver.xml設定ファイルにもこの配置位置を反映させる必要があります。 keytool -genkey -alias tomcat -keyalg RSA \ -keystore /path/to/my/keystore After executing this command, you will first be prompted for the keystore password. The default password used by Tomcat is "changeit" (all lower case), although you can specify a custom password if you like. You will also need to specify the custom password in the server.xml configuration file, as described later. After executing this command, you will first be prompted for the keystore password. The default password used by Tomcat is "changeit" (all lower case), although you can specify a custom password if you like. You will also need to specify the custom password in the server.xml configuration file, as described later. このコマンドを実行した後には、最初にkeystoreの パスワードの入力がうながされます。Tomcatで使用されている デフォルトのパスハードは(すべて小文字)で"changeit" です。パスワードは好きなように変更可能です。 Next, you will be prompted for general information about this Certificate, such as company, contact name, and so on. This information will be displayed to users who attempt to access a secure page in your application, so make sure that the information provided here matches what they will expect. 次に、この証明のための会社名（団体名）、連絡先などの一般的な情報の入力が求められます。この情報はアプリケーションが保護されたページにアクセスを試みるために表示が行われるので、この情報がサイトの訪問者が予測できるようなかたちにしてください。 Finally, you will be prompted for the key password, which is the password specifically for this Certificate (as opposed to any other Certificates stored in the same keystore file). You MUST use the same password here as was used for the keystore password itself. (Currently, the keytool prompt will tell you that pressing the ENTER key does this for you automatically.) 最後になりますが、他の認証が同一のkeystoreファイルに保存されることとは対照的に、この認証のためだけにキーのパスワードの入力が求められます。必ずkeystore自身のパスワードと同一のパスワードを使用しなければなりません。keytoolのプロンプトはENTERキーがこの役目を自動的に担うことを通知します。 If everything was successful, you now have a keystore file with a Certificate that can be used by your server. ここまですべてがうまくいったら、サーバが使用する、証明つきのkeystoreファイルがあることとなります。

Edit the Tomcat Configuration File Tomcatの設定ファイルを編集する

The final step is to configure your secure socket in the $CATALINA_HOME/conf/server.xml file, where $CATALINA_HOME represents the directory into which you installed Tomcat 4. An example <Connector> element for an SSL connector is included in the default server.xml file installed with Tomcat. It will look something like this: <-- Define an SSL HTTP/1.1 Connector on port 8443 --> <!-- <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" scheme="https" secure="true"> <Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="false" protocol="TLS"/> </Connector> --> 最後のステップは$CATALINA_HOMEがしめすTomcat4をインストールしたディレクトリにある$CATALINA_HOME/conf/server.xmlの中にある安全なソケットを設定することです。 SSL Connectorのための<Connector>要素の例が、Tomcatとともにインストールされたデフォルトのserver.xmlファイルにあります。これは、以下にしめすようなかたちです。 <-- Define an SSL HTTP/1.1 Connector on port 8443 --> <!-- <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" scheme="https" secure="true"> <Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="false" protocol="TLS"/> </Connector> --> You will note that the Connector element itself is commented out by default, so you will need to remove the comment tags around it. Then, you can customize the specified attributes as necessary. For detailed information about the various options, consult the Server Configuration Reference. The following discussion covers only those attributes of most interest when setting up SSL communication. デフォルトではConnector要素自身がコメントアウトされていることにお気づきでしょう。 このコメントタグをはずしてください。 そして特定の要素を必要に応じてカスタマイズすることができます。 さまざまなオプションについてはServer Configration Refference（サーバ設定リファレンス）を参照してください。 以下ではSSL通信の最重要な要素についてのみ解説しています。 The port attribute (default value is 8443) is the TCP/IP port number on which Tomcat will listen for secure connections. You can change this to any port number you wish (such as to the default port for https communications, which is 443). However, special setup (outside the scope of this document) is necessary to run Tomcat on port numbers lower than 1024 on many operating systems. ポートの属性（デフォルト値は8443）はTomcatが安全な接続を受け付けるTCP/IPポート番号です。 これを望むポート番号に（例えばhtt$ps通信のポート番号が443であるように）変更することができます。 このドキュメントの範ちゅうからははずれますが、特別なセットアップが多くのオペレーティングシステムにおいて1024より低いポート番号で実行するにあたって重要です。 If you change the port number here, you should also change the value specified for the redirectPort attribute on the non-SSL connector. This allows Tomcat to automatically redirect users who attempt to access a page with a security constraint specifying that SSL is required, as required by the Servlet 2.3 Specification. ここでポート番号を変えたのであれば、SSLでないConnectorのredirectPort属性の値も変更する必要があります。これは（Servlet 2.3仕様が要求するのと同じくして）SSLが必要とされる特定を強制するページにアクセスを試みるユーザに対してTomcatが自動的にリダイレクトできるようにします。 You will notice a Factory element nested inside the Connector element. This is where the "socket factory" used by Tomcat, whenever it needs a socket on the corresponding port number, is configured. You may need to add or change the following attribute values, depending on how you configured your keystore earlier: Connector要素にネストするかたちでFactory要素がありますが、これはTomcatが使用する"socket factory"がある場所であり、一致するポート番号上のソケットを必要とするときに設定されます。 前途のkeystoreをどう設定したかに依存するかたちで、下記の属性の値を追加したり変更することができます。 属性 説明 className このSocket Factoryをimplementする完全なJavaクラスの名前です。デフォルト値を変えてはいけません。 clientAuth TomcatにすべてのSSLクライアントにこのソケットを使用するためにクライアント認証を行わせるときには、この値をtrueにしてください。 keystoreFile 生成した.keystoreファイルがTomcatが予測するデフォルトの位置にない場合にこの属性を追加してください。 絶対パス名、もしくは$CATALINA_BASE環境変数で解決される相対パス名を指定することができます。 keystorePass Tomcatが予測する"changeit"と異なるkeystore（と認証）を使用した際にはこの要素を追加してください。 protocol このソケットにおいて使用される暗号化／非暗号化のプロトコル。 デフォルトの値を変更しないでください。 Attribute Description className The fully qualified class name of the Java class that implements this socket factory. Do not change the default value. clientAuth Set this value to true if you want Tomcat to require all SSL clients to present a client Certificate in order to use this socket. keystoreFile Add this attribute if the keystore file you created is not in the default place that Tomcat expects (a file named .keystore in the user home directory under which Tomcat is running). You can specify an absolute pathname, or a relative pathname that is resolved against the $CATALINA_BASE environment variable. keystorePass Add this element if you used a different keystore (and Certificate) password than the one Tomcat expects (changeit). protocol The encryption/decryption protocol to be used on this socket. Do not change the default value. After completing these configuration changes, you must restart Tomcat as you normally do, and you should be in business. You should be able to access any web application supported by Tomcat via SSL. For example, try: https://localhost:8443 これらの設定を終えた後には、普段しているようにTomcatを再起動する必要があります。元に戻ってください。SSL経由でのTomcatでサポートされるさまざまなWebアプリケーションにアクセスができるべきです。 試してみてください： https://localhost:8443 and you should see the usual Tomcat splash page (unless you have modified the ROOT web application). If this does not work, the following section contains some troubleshooting tips. 上記ではROOTのWebアプリケーションを変更することなしにTomcatおなじみの画面が現れます。表示されない場合には以下のページのトラブルシューティングを参照してください。

Here is a list of common problems that you may encounter when setting up SSL communications, and what to do about them.

これはSSL通信を行う際に直面するであろう一般的な問題のリストです。どうすべきかを示します。

• I get "java.security.NoSuchAlgorithmException" errors in my log files.

  The JVM cannot find the JSSE JAR files. Follow all of the directions to download and install JSSE.

• ログファイルに"java.security.NoSuchAlgorithmException"があります。

  使用しているJVMがJSSEのJARファイルを見つけられていません。JSSEのダウンロードとインストールで使用法をひととおり見てください。

• When Tomcat starts up, I get an exception like "java.io.FileNotFoundException: {some-directory}/{some-file} not found".

  A likely explanation is that Tomcat cannot find the keystore file where it is looking. By default, Tomcat expects the keystore file to be named .keystore in the user home directory under which Tomcat is running (which may or may not be the same as yours :-). If the keystore file is anywhere else, you will need to add a keystoreFile attribute to the <Factory> element in the Tomcat configuration file.

• Tomcatを立ち上げるときに"java.io.FileNotFoundException:{ディレクトリ名}/{ファイル名}" が見つかりません。"という例外を見かけます。

  近しい説明はTomcatが見ている範ちゅうでkeystoreファイルを見つけられないということです。デフォルトでTomcatは稼動しているユーザホームディレクトリ配下（これは設定によって異なります:-）の.keystoreファイルがあることを予期しています。 keystoreファイルが別の場所にあるのであれば、前のステップに戻ってkeystoreファイルを再度生成するか、keystoreファイルが別のディレクトリにあるのであり、Tomcat設定ファイルの<Factory>要素にkeystoreファイルと別のディレクトリにあるのであれば、keystoreFile属性を加える必要があります。

• When Tomcat starts up, I get an exception like "java.io.FileNotFoundException: Keystore was tampered with, or password was incorrect".

  Assuming that someone has not actually tampered with your keystore file, the most likely cause is that Tomcat is using a different password than the one you used when you created the keystore file. To fix this, you can either go back and recreate the keystore file, or you can add or update the keystorePass attribute on the <Factory> element in the Tomcat configuration file. REMINDER - Passwords are case sensitive!

• Tomcatの起動時に"java.io.FileNotFoundException:keystoreが変更されたか パスワードが違います"という例外を見かけるのですが。

  keystoreファイルが第三者によって不正に変更されていないか確認してください。最も多い理由はTomcatがkeystoreファイルが生成されたときと違うパスワードを使用していることです。 これを修正するには、keystoreファイルの再生成をするか、もしくはTomcat設定ファイル<Factory>要素にあるkeystorePass属性を変更するか追加してください。 パスワードでは大文字小文字が区別されることを忘れないでください。

If you are still having problems, a good source of information is the TOMCAT-USER mailing list. You can find pointers to archives of previous messages on this list, as well as subscription and unsubscription information, at http://jakarta.apache.org/site/mail.html".

それでもなお問題があるのであれば、Tomcat-Userメーリングリストが良い情報源になります。過去のリストに情報があることでしょう。ＭＬに参加することについての情報はhttp://jakarta.apache.org/site/mail.html"を参照してください。