Javaサーブレット内にSSL認証処理を実装しなければならないのですが、
そもそも一般的にどのような実装をされているかというところが理解出来ておりません。。

理解不足で大変申し訳ござませんが、ご教示の程宜しくお願い致します。

SSL認証処理についての今の理解

###★事前準備(インフラ)
【サーバー側準備】
■キーストア構築
0. キーペアの作成
0. CSRの作成
認証局に証明書を発行してもらうためにサーバーの情報を格納したものを作成
0. 認証局にCSRの提出
0. サーバー証明書の取得
0. サーバー証明書のインポート

■トラストストア構築
0. クライント側のルート証明書をインポート

【クライアント側準備】
■キーストア構築
0. キーペアの作成
0. CSRの作成
0. 認証局にCSRの提出
0. サーバー証明書の取得
0. サーバー証明書のインポート

■トラストストア構築
サーバー側のルート証明書をインポート

上記事前準備が整ったらJavaの実装ができると考えておりますが、

Q①：実際は「サーバー認証」のみであれば、サーバー側の証明書の準備が整っていれば
十分なのではと考えておりますが、あっておりますでしょうか？

★Java実装

色々なWebページのソースを参照させていただいたのですが、
記載方法が各々異なり、どれが正であるかの判断がつきかねましたので、
すみませんが、

Q②：SSL認証を考慮した実装方法をご教示ください。。(HttpsURLConnectionを使用したもの)
setSSLSocketFactory等を使用？？
★追記：HTTPSリクエストを送信するクライアント(リクエストを送信するサーブレットが置かれているサーバー)
⇔受信サーバー(サーブレットからのリクエストを受けて結果を返すサーバー) 間のクライアント認証部分になります。

また、SSL認証処理について具体的には以下の２種類の観点があるのかと考えております。

サーバー認証：サーバーのキーストアにインストールされている証明書の中身について処理
クラアント認証：サーバー側で利用される予定のクライアントからのアクセスであることを認証する為の処理

Q③：クライアント側の実装する際は「サーバー認証」にて証明書の中身の妥当性を判断する場合に、
SSL認証処理を実装する必要があると考えて良いでしょうか？
※単に中身について見ないのであれば下記Javaのように普通につなぎに行って良いものでしょうか？
HttpURLConnectionを使用しても問題ない認識でサーバー認証は裏でやってくれると思っております。

lang
1package jp.co.bussiness.servlet.connect;
2
3import java.io.IOException;
4
5import javax.servlet.ServletException;
6import javax.servlet.http.HttpServlet;
7import javax.servlet.http.HttpServletRequest;
8import javax.servlet.http.HttpServletResponse;
9
10import org.apache.commons.httpclient.HttpClient;
11import org.apache.commons.httpclient.URIException;
12import org.apache.commons.httpclient.methods.PutMethod;
13import org.apache.commons.httpclient.methods.RequestEntity;
14import org.apache.commons.httpclient.methods.StringRequestEntity;
15import org.apache.commons.httpclient.util.URIUtil;
16
17public class HttpClientFrom extends HttpServlet {
18
19	@Override
20	public void doGet(HttpServletRequest req, HttpServletResponse resp)
21			throws ServletException, IOException {
22
23		System.out.println(this.getClass().toString() + "▼処理開始▼");
24
25		String url = "https://example.trust.co.jp/connection/ssl"; //★Https指定★
26		HttpClient client = new HttpClient();
27		PutMethod method = new PutMethod(url);
28		method.setRequestHeader("Content-Type", "text/plain; charset=UTF-8");
29
30		String body = "members-id=" + URIUtil.encode("A=9999", null) + "&"
31				+ "members-name=" + URIUtil.encode("テスト=管理者", null) + "&"
32				+ "address="  + URIUtil.encode("テス都テスト区テスト町９丁目９－９９&マイハウス", null);
33
34		RequestEntity entity = new StringRequestEntity(body, null, "utf-8");
35
36		method.setRequestEntity(entity);
37
38		int statusCode = client.executeMethod(method); //★接続★
39
40		log("Httpステータス : " +  statusCode);
41
42		System.out.println(this.getClass().toString() + "▲処理終了▲");
43
44		resp.setContentType("text/html; charset=UTF-8");
45		resp.getWriter().write(
46				"<html>"
47				+ "<head></head>"
48				+ "<body>"
49				+ "<h1>クラス : "+ this.getClass().toString() + "</h1>"
50				+ "</br>"
51				+ "レスポンスコード  : " + statusCode +
52				"<br/>" +
53				"<a href=\"/MyCat/\">トップページに戻る</a>"
54				+ "</body>"
55				+ "</html>"
56				);
57
58	}
59
60}
61
62

【SSL認証参考URL】

※下記ページの内容を踏まえて前述の考えに及びました。
▼SSL認証処理サンプル
https://codezine.jp/article/detail/105

▼一方向認証(サーバー認証)と双方向認証(クライアント・サーバー認証)
http://otndnld.oracle.co.jp/document/products/wls/docs103/secmanage/ssl.html

一方向および双方向 SSL

SSL は、一方向または双方向としてコンフィグレーションできます。

一方向 SSL では、サーバはクライアントに対して証明書を提示する必要があるが、クライアントはサーバに対して証明書を提示する必要がない。クライアントはサーバを認証する必要がありますが、サーバはどのクライアントからの接続も受け入れます。一方向 SSL は、インターネット上で顧客が個人データを共有する前にセキュアな接続を実現したい場合によく使用されます。クライアントがログインするときにも、サーバが認証できるように SSL を使用することがよくあります。
双方向 SSL (SSL とクライアント認証) の場合、サーバはクライアントに証明書を提示し、クライアントはサーバに証明書を提示する。クライアントが有効で信頼性のある証明書を発行しなければ SSL 接続を確立できないように WebLogic Server をコンフィグレーションできます。

▼サーバー認証は接続に言ったタイミングで裏で処理してくれると思った理由

SSLのハンドシェイク実行時に、SSLサーバからSSLクライアントにサーバ証明書が送信されます。

そのサーバ証明書の検証はどこで行っているのでしょうか？

中で既に標準的な検証は実装されています。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10140922810

▼HttpURLConnectionでもよいと思った理由

接続先がhttpsの場合url.openConnection()が実際戻すクラスはHttpsURLConnection ですが、HttpURLConnectionの派生であるため、特に意識することなく使用できます。

HttpsURLConnectionを使った送受信ではデータは暗号化されますが、意識する必要はありません。
https://ssltest2.verisign.co.jp/はベリサイン社のHTTPS検証サイトです。
GETでもPOSTでも簡単な応答を返してくれます。サンプルプログラムでは無意味なXMLを送っていますが、無視してくれます
http://k-hiura.cocolog-nifty.com/blog/2012/04/javahttphttps-1.html#navi_bar

Q④：下記URLにある実装で「SSL証明書の検証無効化とホスト名検証を無効化」する
理由(メリット)は何なのでしょうか？
http://d.hatena.ne.jp/Kazuhira/20141004/1412441208

以上4点になります。
すみませんが、ご教示の程宜しくお願い致します。

A-pZ

2016/07/13 14:27

実施したいことがどちらなのだろうか…と思いました。サーバ認証は Q①でよいです。クライアント認証について、少し確認させてください。行いたいのは、Q①から続いて、そのサーバとそのサーバのアプリケーションを使うブラウザ間のクライアント認証でしょうか。それとも、サーバから別のHTTPSリクエストを投げるにあたって、別のサーバと通信する際にクライアント認証をしたいということでしょうか。

tutttwi

2016/07/13 15:02

A-pZさんいつもありがとう御座います。具体的に実装したいと思っているのは、サーブレットからのHTTPS通信でのSSL認証になります。その際のロジックとして、特別SSL認証の為にロジック追加する必要が有るかどうかを懸念しております。情報が不足しておりましたらすみませんがご指摘ください。

A-pZ

2016/07/15 10:41

なるほど詳細にありがとうございました！考え方としては間違っておりません。別途SSL用の通信ソケットを立ち上げることになりますが、JavaSecurityの中で実装済みのクラスを利用して、あとは秘密鍵を生成→認証局からクライアント証明書(公開鍵)の発行の流れは一緒です。ちなみにSSL証明書の無効化は、無効化リスト(CRL)に書かれた証明書が存在するかをチェックするもので、上位の認証局によってその証明書を発行したが、有効期限が切れる前に何か不都合があったため取り消しました、を示すものです。

行動規範の内容に同意します

回答3件

ベストアンサー

お返事遅くなりました。

Strong Authenticationとは、SSLの場合今回のようにサーバー認証とクライアント認証を合わせて利用する時にそう呼称します。

参考書の定番では、「マスタリングTCP/IP SSL/TLS編」ですかね。ただ高いので、「食べる！SSL！ ―HTTPS環境構築から始めるSSL入門」 Kindle版なら３２０円です。

ウェブにも色々情報はありますから、それを見てよく判らない所を書籍で補うのが良いでしょう。
Googleで「SSL 解説」とかで検索すると、結構色々なサイトがヒットします。
私のオススメは、ココと、ココです。

投稿2016/08/02 05:14

編集2016/08/02 05:20

tsuntsun

総合スコア199

tutttwi

2016/08/02 15:03

追加のご回答ありがとう御座います。 Strong Authentificationってそのような意味だったのですね！納得致しました。！参考書、Webページのご提示ありがとう御座います。まさに私の知りたかった情報でした！この度はお忙しい中、ご回答頂きありがとう御座います。

行動規範の内容に同意します

Q①：実際は「サーバー認証」のみであれば、サーバー側の証明書の準備が整っていれば十分なのではと考えておりますが、あっておりますでしょうか？

サーバ証明書が、パブリックなCA（ベリサインやグローバルサイン等）から発行されたものならその通りです。
そうでない場合（オレオレ証明書）には、クライアント側のTrustKeyStoreにRootCAを登録する必要があります。

Q②：SSL認証を考慮した実装方法をご教示ください。。(HttpsURLConnectionを使用したもの)setSSLSocketFactory等を使用？？具体的に実装したいと思っているのは、サーブレットからのHTTPS通信でのSSL認証になります。

これが意味不明です。
単純にサービスを提供しているサーブレットにアクセスするクライアントを、クライアント認証を
使ったStrong Authを行いたいのですか？
わざわざ「サーブレットからのHTTPS通信」と書かれているので、サーブレット側から何処かに
新たにSSLを張るのでしょうか？
前者であれば、わざわざサーブレットで実装しなくても、APサーバで面倒見てくれますが。
（少なくとも、TomcatやJBoss,Glasfishはやってくれます）

Q③：クライアント側の実装する際は「サーバー認証」にて証明書の中身の妥当性を判断する場合にSSL認証処理を実装する必要があると考えて良いでしょうか？※単に中身について見ないのであれば下記Javaのように普通につなぎに行って良いものでしょうか？ HttpURLConnectionを使用しても問題ない認識でサーバー認証は裏でやってくれると思っております。

裏でやってくれます。

Q④：下記URLにある実装で「SSL証明書の検証無効化とホスト名検証を無効化」する理由(メリット)は何なのでしょうか？

証明書の有効性を確認しに行かないので、SSL開始時のセッションが少し早くなります。
但しサーバに使われている証明書がEV対応であるならば、絶対に無効化してはいけません。
EV証明書の意味がなくなってしまいます。
＃詳細は長くなるので、省略させて下さい m(_ _)m

投稿2016/07/22 10:17

編集2016/08/02 05:16

tsuntsun

総合スコア199

tutttwi

2016/07/31 11:46

ご回答有り難うございます。 >サーバ証明書が、パブリックなCA（ベリサインやグローバルサイン等）から発行されたものならその通りです。そうでない場合（オレオレ証明書）には、クライアント側のTrustKeyStoreにRootCAを登録する必要があります。オレオレ証明書とパブリックな証明書についての区別が今ひとつでしたが、調査の上理解を深めることができました。 >Strong Authを行いたいのですか？ Strong Authという言葉を初めて聞きました。無知で申し訳ございませんが、Strong Authがホスト名の検証とかの処理の総称であっていましたら、Strong Auth の認証処理のことを言っています。 >証明書の有効性を確認しに行かないので、SSL開始時のセッションが少し早くなります。そうなんですね。！EV証明書についても存じておりませんでしたので、とても参考になりました。 SSL認証についてふわっとした知識しかないのでとても不安です。追加で大変恐縮なのですが、もし参考になる書籍やページをご存知でしたらご教示頂きたいです。

行動規範の内容に同意します

うーん...どこから教えたものかな。

まず簡単なところからいきましょうか。

Q④：下記URLにある実装で「SSL証明書の検証無効化とホスト名検証を無効化」する

理由(メリット)は何なのでしょうか？

SSL証明書の検証無効化とホスト名検証の無効化のメリットは、CAで認証された正式のSSL証明書が不要になること、と言って良いと思います（IoTの場合など、クライアントの負荷を少しでも下げたい場合に選択することも、理屈の上では考えられますが、私がそれを迫られたことはありません）。正式のSSL証明書は、取得に費用や手間がかかりますから、開発の初期段階では無効化しておきたくなったり、あるいは経路さえ暗号化されていれば十分で、サーバのなりすましのことは心配しなくて良い、という要件なのであれば、検証の無効化はメリットがあると思います。

Q③：クライアント側の実装する際は「サーバー認証」にて証明書の中身の妥当性を判断する場合に、

SSL認証処理を実装する必要があると考えて良いでしょうか？

上記「SSL証明書の検証無効化とホスト名検証を無効化」と関連しますが、サーバ証明書の妥当性を判断するには普通にHttpClientを使えば十分です。デフォルトで妥当性を検証してくれます(だからこそ、検証したくないときはわざわざ無効化しないといけないわけです)。

クライアント証明書を使う場合には、クライアント証明書をJREの証明書ストアにインポートした上で、インポートした証明書を使うように指定する必要があります。

で、サーバ認証とかクライアント認証とかの話ですけどね。

まず、クライアント証明書を使った認証は、クライアント毎の証明書を発行してインストールする手間があるので、もっとも敷居が高いです。逆に言えば、もっともセキュアです。証明書を持っていないクライアントからのアクセスを拒否できるし、特定のクライアント証明書を無効にすることもサーバ側でできるので強力です。しかし、たしかに面倒が多いので、そこまでする必要がないかぎりはその認証はしないのが普通だと思います。

次にサーバサイドの認証ですが、いろいろ方法があります。

ApacheやnginxでBASIC認証ないしDigest認証した上でTomcat等のServletコンテナにproxyする手もあるし、Tomcat等のServletコンテナの認証機能を使う手もあります。これらの方法を使う場合、Servlet側では認証は実装しません。私は、これらの方法を使うことをオススメします。サーバサイドの認証を自力で実装するより、既存の機能を使った方が楽ですし、ノウハウも世間に蓄積されているからです。

どうしてもサーバサイドの認証をServlet側で実装するのであっても、Apache Shiroのようなライブラリを使うとか、Webアプリケーションフレームワークの認証機能を使う方が良いと思います。

投稿2016/07/22 09:58

chokojori

総合スコア973

tutttwi

2016/07/31 11:54

ご回答ありがとう御座います。 >正式のSSL証明書は、取得に費用や手間がかかりますから、開発の初期段階では無効化しておきたくなったり、あるいは経路さえ暗号化されていれば十分で、サーバのなりすましのことは心配しなくて良い、という要件なのであれば、検証の無効化はメリットがあると思います。 >クライアント証明書...敷居が高い。もっともセキュア... 上記とても参考になりました。このような要件時に無効化されているのですね。 >サーバーサイド認証ですが... 基本的にソースで実装はせず、コンテナ等で提供されているんですね。ご教示頂き、ありがとう御座います。 SSL認証についてふわっとした知識しかないのでとても不安です。追加で大変恐縮なのですが、もし参考になる書籍やページをご存知でしたらご教示頂きたいです。

行動規範の内容に同意します

あなたの回答