山形大学
情報ネットワークセンター



そのほかの学内のいろいろなサービスについて!

センターはIT専門部署と言うわけではありません。どちらかと言うとIT利用の基盤を運用するのが仕事です。 センターが行っているサービスとは別に、それぞれの部署で様々なサービスを行っています。 例えば人事系、財務系、学務系、それ以外の業務サービスについてはそれぞれの専門部署で運用しております。 センターでは情報がありませんので、直接、担当部署に相談ください。

なお、以下のような学外との連携サービスもあります。

NII File Sender について
国立情報学研究所による学認を利用したサービスです。メールに添付できない大きなファイルを受け渡しするためのサービスです。
使い方
  • ブラウザで NII FileSender にアクセスし「ログイン」ボタンを押す。
  • 「所属機関の選択」画面でプルダウンメニューから山形大学を選択する。
  • Yamagata University Login Page が開くので「Username」欄にセンターのIDを「Password」欄にパスワードを入力する。
  • ファイル送信画面に切り替わるので以下の情報を入力する。
    • (a) [To:] ファイルを送りたい相手先のメールアドレスを入力します。
    • (b) [件名:] メールの件名です。
    • (c) [メッセージ:] 相手への要件を入力します。
    • (d) [有効期限:] 最大20日まで設定できます。
    • (e) 「参照」ボタンを押して送りたいファイルを選択します。
  • (5) 「送信」ボタンを押すとファイルへのリンクが書き込まれたメールが送信されます。
利用上の注意
  • 受信側からのファイルアクセスについてパスワードを設定することはできま せん。転送するファイルの重要度・機密性に鑑み、ファイルそのものにパスワー ドを設定する等、ファイルのセキュリティ管理については利用者自らがおこなっ てください。(ファイルの有効期限も短く設定することをおすすめします。)本 サービスを利用したことによるセキュリティリスクは、利用者本人が負うものと します。
  • 本サービスを利用したことによるファイルの消失、壊変、あるいは送信側・ 受信側のシステムの不調等についてのお問い合わせには一切応じることはできま せん。ご利用にあたっては、あらかじめ送信テストを実施していただく等、利用者自らが慎重に準備してください。
  • 日本語ファイル名については文字化けする可能性もありますので、ファイル名は短く解りやすい英数字にすることをおすすめします。
  • 本サービスは国立情報学研究所が提供しているサービスで、ご利用の皆様に提供できる情報は以下のサイトで提供されているもののみとなります。
  • その内容や仕様等についての質問や要望等を、情報ネットワークセンターでは承れませんので、あらかじめご了承願います。
  • 予告なく本サービスの内容が変更、休止、終了する場合もありますので、あらかじめご了承願います。
サーバ証明書発行業務
  • サーバ証明書とはWebサイト等のサーバの身元証明を電子的におこなうためサービスです。
  • 単純に言えば、http(保護されていない) から エラーが出ないような正式な https に変更することでしょうか
  • NIIが行っているUPKI電子証明書発行サービスと言う証明書発行事業があります。
  • 山形大学ではその事業と連携し、センターでは発行申請の代行を行っております。
  • セキュリティの事情により、自動更新のサービスも利用可能になりました。
サーバ証明書の自動更新について
昨今のセキュリティ情勢により、サーバ証明書の有効期限は短縮され続けています。 最終的には 有効期限が 47 日 まで短くなることが決まっています。
短縮のロードマップ
最大有効期間
現状200日
2027年3月15日以降100日
2029年3月15日以降47日

ここまで期限が短くなると、手作業による証明書更新は現実的ではありません。
そのため、サーバ証明書の更新作業は 自動化 を前提とした運用に移行する必要があります。 早いうちに移行の準備を進めるようにしてください。
自動化は大きく分けて 2つ の方法と 2つ の申請先があります。
2つの方法について (HTTP-01 チャレンジ と DNS-01 チャレンジ)
2つの方法とは、HTTP-01 チャレンジ と DNS-01 チャレンジの2つです。
一般的には HTTP-01 チャレンジのほうが設定難易度が低く、導入しやすい方法です。
ただし、どちらを選ぶべきかは サーバの役割・公開範囲・ネットワーク構成 によって変わります。
それぞれを選ぶ大まかな基準は以下の通りです。
  • HTTP-01 チャレンジを選べるケース
    • 大学外部に公開している Web サーバ
    • 80 番ポートを外部に開けられるサーバ
    • .well-known/acme-challenge/ を返せる Web サーバが動いている
    • Web サーバのほとんどがこれに該当します。
  • DNS-01 チャレンジを選ぶべきケース
    • 学内限定サービス
    • ロードバランサーや CDN を挟んでいる
    • 学外に80を公開できない(機能が無い、セキュリティ上等)
  • 注意:クラウドでサーバを借りている場合
  • クラウド環境では、証明書の扱いがサービスや業者によって異なります。
    • AWS などの大手:証明書サービス(ACM)が自動更新を肩代わり
    • 一般的な VPS:HTTP-01 チャレンジが使えるかどうかを確認
    クラウド利用者は、そのクラウドがどのように証明書更新をサポートしているかを確認してから契約してください。
2つの申請先(Let’s Encript と NII )
サーバ証明書を自動で更新するための申請先も複数あります。山形大学で利用できる申請先のうち、Let’s Encript と NII について簡単に紹介させていただきます。
なお、クラウドの場合はこれらを使える場合もありますし、クラウド独自の方法になる場合もあります。
  • 1. NII(UPKI)ルート【推奨:公式・高信頼】
    • 特徴:大学の名前が証明書に刻まれる「公式な証明書(組織認証型)」です。
    • メリット:学外の一般利用者や学生がアクセスする「公式WEBサイト」や「教務システム」に最適です。セキュリティ監査も問題なくクリアできます。
    • 注意点:事前に学内窓口から「認証用のキー(KID/HMAC)」を発行してもらう初期設定が必要です。また、ワイルドカード(*)は使えません。
  • Let's Encrypt ルート【手軽:検証・学内向け】
    • ・特徴:世界中で使われている、誰でも無料で即座に発行できる暗号化証明書です。
    • ・メリット:事前申請が一切不要で、コマンド一つで今すぐ利用できます。ワイルドカードも使えます。
    • ・注意点:組織名(大学名)の証明は載りません。また、大学公式ドメイン(ac.jp)以外の独自ドメインでも発行できてしまうため、公的な信頼性はNIIより低くなります。

申請先についてはどちらも問題ありませんが、より公式なサービス、より信頼性のあるサービスを行う場合は NII を利用したほうがいいでしょう。
また、将来において組織証明のないサーバ証明書で運営されているサイトはサービスの制限など行われる可能性もありますので、 公式なサイトやデータのやり取りが必要なサイトはできるだけ NII を申請先として設定できるよう準備しましょう。

申請先は複数ありますが、設定していくにあたり、まず、Let's Encrypt に設定してみることをおススメします。
Let's Encrypt に設定できれば、他の申請先に変更するのはそれほど手間ではありません。
HTTP-01 チャレンジ と DNS-01 チャレンジ のどちらの方法を選択する場合でも同じです。
うまくいかない場合に原因を特定するための切り分けにもなりますので、まずはLet's Encryptに設定してみましょう。

HTTP-01 チャレンジの準備方法・実施方法(一例)
  1. DNS が正しくサーバを向いているか確認する
  2. Web サーバが .well-known/acme-challenge/ を返せる状態にする
    • リダイレクト設定(HTTP→HTTPS)に注意
    • .well-known/acme-challenge/ は HTTPS へリダイレクトしないようにする
  3. Certbot(または acme.sh)を導入する
  4. 既存証明書を置き換える形で「更新」する
    • certbot certonly --webroot -w /var/www/html -d XXXXX.yamagata-u.ac.jp
      ( XXXXX は読み替えてください)
    • 既存証明書があっても問題なく更新扱いになる
  5. 自動更新を設定する
    • certbot renew を cron 等で定期実行設定する
    • Webroot を指定する場合は --webroot -w /var/www/html を付ける(/var/www/htmlは適宜読み替え)
  6. 更新を行う(動作確認)
    • certbot renew --dry-run でテスト
    • Web サーバの設定ファイルが Certbot の証明書パスを参照しているか確認
    • 更新後に Web サーバを reload する設定も必要に応じて追加
その後、自動実行のスケジュールに合わせて証明書が更新されるようになりますが、
念のため、更新スケジュールは少し早めにして、更新されたかをブラウザなどで確認するようにしてください。
絶対に更新に成功するとは限りませんので、失敗している場合は手動で処理してください。
この場合の手動は上記コマンドになります。
[an error occurred while processing this directive]
Linux での設定方法(1例)
あくまで1例です。方法は複数あります。また、すべてが同じ方法でうまくいくとは限りません。
適宜、うまくいかない部分などは自分で調べたり、保守業者と相談してください。 [an error occurred while processing this directive]
Windows での設定方法(1例)
あくまで1例です。方法は複数あります。また、すべてが同じ方法でうまくいくとは限りません。
適宜、うまくいかない部分などは自分で調べたり、保守業者と相談してください。 [an error occurred while processing this directive] [an error occurred while processing this directive]
NII / UPKI ACME への切り替え
cmd (コマンドプロンプト)、あるいはshare point から 以下のコマンドを打つ。
wacs.exe ^
  --baseuri "https://secomtrust-acme.com" ^
  --accepttos ^
  --emailaddress "【サーバ管理者のメールアドレス】" ^
  --eab-key-identifier "【NIIから取得したKID】" ^
  --eab-key "【NIIから取得したHMAC Key】"
※PowerShellの場合は ^ を ` に変更するか、改行せずに1行で入力してください