14:51:13.419 - INFO [edu.internet2.middleware.shibboleth.common.config.BaseService:158] - Loading new configuration for service shibboleth.RelyingPartyConfigurationManager
14:51:13.506 - ERROR [edu.internet2.middleware.shibboleth.common.config.BaseService:188] - Configuration was not loaded for shibboleth.RelyingPartyConfigurationManager service, error creating components.  The root cause of this error was: org.xml.sax.SAXParseException: The entity name must immediately follow the '&' in the entity reference.

→上記のエラーは relying-party.xml にXML文法としての間違いがある場合に出力されます。
→例えば relying-party.xml にパスフレーズ付きの証明書を設定するとき、パスフレーズに '&' や '<' を含む場合はこれらの文字列をそのまま設定することはできません。これらの文字を含む場合は文字参照で & や < のように記述してください。

• 誤ったパスフレーズ設定例

      <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
        <security:PrivateKey Password="myKeyPa$$word&">
                /opt/shibboleth-idp/credentials/server-enc.key
        </security:PrivateKey>

• 正しいパスフレーズ設定例

      <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
        <security:PrivateKey Password="myKeyPa$$word&amp;">
                /opt/shibboleth-idp/credentials/server-enc.key
        </security:PrivateKey>

javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null

→ SSLv3のみをサポートしたWebサーバ（TLSv1.0, TLSv1.1, TLSv1.2等をサポートしていない）からメタデータを取得するときに出力されるエラーメッセージです。

→ relying-party.xmlのメタデータ取得の設定で、MetadataProviderのオプション disregardSslCertificate="true" を設定した場合、もしくはIdP 2.3.xの場合には下記の通りエラーログが変化します。 disregardSslCertificate の詳細は https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider#IdPMetadataProvider-FileBackedHTTPMetadataProvider をご参照ください。

javax.net.ssl.SSLException: Received fatal alert: bad_record_mac

→ 上記「SSL peer failed hostname validation for name: null」、「Received fatal alert: bad_record_mac」のエラーはIdP 2.4.0, 2.4.3 で確認しています。

→ IdP 2.4.3においてはMetadataProviderのオプション disregardSslCertificate の設定の有無に関係なく、JDKのオプション -Dcom.sun.net.ssl.rsaPreMasterSecretFix=true を設定することで、SSLv3のみをサポートしたWebサーバからメタデータの取得ができることを確認しています。
※SSLv3のみサポートしたWebサーバとして CentOS 6 (httpd-2.2.15-39.el6.centos.x86_64) で確認していますが、他のWebサーバ実装ではJDKのオプションを設定せずにメタデータが取得できるかもしれません。この場合上記オプションを設定することで逆にエラーになる可能性がありますのでご注意ください。

→ IdP 3.0.0-beta1ではSSLv3のみをサポートしたWebサーバへは上記設定に関わらずアクセスできないことを確認しています。Webサーバ側でTLSのサポートをご検討ください。

Error Message: SAML 2 SSO profile is not configured for relying party https://sp.example.ac.jp/shibboleth-sp

→relying-party.xmlにこのSPだけに対する特殊な<RelyingParty>設定があり、かつその中に SAML2SSOProfile の設定が抜けているとこのエラーになります。
　もしくは、このSPが最近追加されたものである場合、IdPが最新のメタデータ取得に失敗している可能性があります。

opensaml::FatalProfileException
The system encountered an error at Tue Apr 30 12:13:14 2013
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
opensaml::FatalProfileException at (https://sp.example.ac.jp/Shibboleth.sso/SAML2/POST)
Message was signed, but signature could not be verified.

→IdPの設定ファイル idp.properties で idp.signing.cert に設定している証明書（対応する秘密鍵は idp.signing.key で指定されていること）と、学認申請システムに登録した証明書が一致することを確認してください。不一致である場合は上記のエラーが出力されます。

→IdPのサーバ証明書を更新するときに idp.properties にて示される証明書ファイルを誤って上書きすると、学認申請システムに登録した証明書と一致しない状態となりエラーとなるケースがあるようです。このケース含め証明書更新過程でのエラーを避けるため、IdPにおけるサーバ証明書の更新方法は 技術ガイド：メタデータ記載の証明書更新手順（IdP） をご参照ください。

opensaml::SecurityPolicyException
The system encountered an error at Tue Apr 30 12:13:14 2013
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
opensaml::SecurityPolicyException at (https://sp.example.ac.jp/Shibboleth.sso/SAML2/POST)
Message expired, was issued too long ago.

→IdPが動作しているホストの時刻がずれている場合に出力されます。NTPなどでホストの時刻を修正してください。
→参考情報 : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTroubleshootingCommonErrors#NativeSPTroubleshootingCommonErrors-opensamlSecurityPolicyExceptionMessageexpiredwasissuedtoolongago

→ 関連して、運用フェデレーションで実運用中のIdPにおいて、テストフェデレーションのメタデータを読み込んでいる場合には、テストフェデレーションのメタデータ読み込み設定を削除してください。運用フェデレーションのメタデータのみを読み込む設定としたほうがより原因を追究しやすい状態となります。

→ transientIdが必須となっているSPにおいて、IdP側でtransientIdの送出が制限されている場合にエラーとなる場合があります。要求されている属性が正しく送出されているにも関わらず認証エラーとなる場合にはtransientIdの送出の有無を確認しておくと問題の切り分けに役立ちます。

→ SPが要求している属性と異なる属性を送出している場合にもエラーとなります。学認のIdP・SP一覧（https://www.gakunin.jp/participants/）で指定されている属性とattribute-filter.xmlの設定が一致しているか見直してください。attribute-filter.xmlを設定後、 設定・運用・カスタマイズ#SPに対してどのような属性が送出されるか確認する方法 の手順で実際に送出される属性を確認することができます。特に「eduPersonAffiliation （スコープなし）」と「eduPersonScopedAffiliation （スコープあり）」は似ていることもあり、間違えやすいことから注意が必要です。

2020-11-27 13:12:52,167 - xxx.xxx.xxx.xxx - ERROR [net.shibboleth.utilities.java.support.security.DataSealer:252] - Exception unwrapping data: Tag mismatch!
2020-11-27 13:12:52,178 - xxx.xxx.xxx.xxx - ERROR [org.opensaml.storage.impl.client.ClientStorageService:453] - StorageService shibboleth.ClientSessionStorageService: Exception unwrapping secured data
net.shibboleth.utilities.java.support.security.DataSealerException: Exception unwrapping data
        at net.shibboleth.utilities.java.support.security.DataSealer.unwrap(DataSealer.java:253)
Caused by: javax.crypto.AEADBadTagException: Tag mismatch!
        at java.base/com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:623)

IdPは、コンポーネントDataSealerにてAES秘密鍵を使ってcookie等を暗号化しています。詳細は SecretKeyManagement を参照してください。

上記エラーは、バージョンアップ等によりIdPに切り替えた際、または複数のIdPによるIdPクラスタリング環境において、コンポーネントDataSealerのAES秘密鍵が異なるため暗号化されたcookie等が復号できなかったことを示すエラーメッセージです。

復号できなかったことにより、IdPは認証済みの情報が取得できず再度ログイン画面を表示して再認証を要求します。

IdPを切り替えた場合は、利用者が新IdPで再認証することで順次新しい秘密鍵で暗号化したcookie等に置き換わりますので、無視しても大丈夫です。無視できない場合は旧IdPからコンポーネントDataSealerのAES秘密鍵をコピーしてください。

IdPクラスタリング環境では、基本的に共通のAES秘密鍵を使う必要があります。1台目のコンポーネントDataSealerのAES秘密鍵をその他のIdPにコピーしてください。

コピーするファイルは下記になります。

• /opt/shibboleth-idp/credentials/sealer.*

[Thu Jun 19 17:00:00 2014] [error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header
[Thu Jun 19 17:00:00 2014] [error] ajp_read_header: ajp_ilink_receive failed
[Thu Jun 19 17:00:00 2014] [error] (120006)APR does not understand this error code: proxy: read response failed from [::1]:8009 (localhost)

→ IdPが正しく動作していない可能性があります。Tomcatを再起動することで解消するとの報告があります。

→ [upki-fed:00493] でも同様の問題が発生していたとの報告があります。

ERROR Shibboleth.AttributeResolver.Query [3]: exception during SAML query to https://IdPのホスト名:8443/idp/profile/SAML1/SOAP/AttributeQuery: CURLSOAPTransport failed while contacting SOAP endpoint (https://IdPのホスト名:8443/idp/profile/SAML1/SOAP/AttributeQuery): error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
ERROR Shibboleth.AttributeResolver.Query [3]: unable to obtain a SAML response from attribute authority

→ この問題に対応した tomcat6-dta-ssl-2.0.0.jar が公開されました （Updated Tomcat 6 Connector, JCONN-2）。

→ Tomcat 6.0.43およびそれ以降のバージョンをご利用の場合は学認技術ガイドの手順（IdP > IdPセッティング > サーバ証明書の設定(IdP) > ２．ライブラリのコピー）に従い tomcat6-dta-ssl-2.0.0.jar を導入し、旧jarファイル tomcat6-dta-ssl-1.0.0.jar（もしあれば tomcat6-dta-ssl-1.1.0.jar も）を削除してください。

Caused by: java.lang.UnsupportedClassVersionError: edu/internet2/middleware/security/tomcat6/DelegateToApplicationJSSEImplementation : Unsupported major.minor version 51.0

ERROR [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:273] - [Timer-0:] - Error retrieving metadata 
from https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml javax.net.ssl.SSLPeerUnverifiedException: SSL peer
 failed hostname validation for name: (メタデータリポジトリのIPアドレス)

※適宜改行を入れていますが実際には一行で出力されます。
→ Tomcatを起動するときのオプションに「-Djdk.tls.trustNameService=true」をつけて起動することで問題が回避できます。

JAVA_OPTS="${JAVA_OPTS} -Djdk.tls.trustNameService=true"

1:19:57.770 - ERROR [org.opensaml.xml.security.SigningUtil:250] - Error during signature verification java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

ブラウザには以下のエラーが表示されます。

Error Message: Message did not meet security requirements

以下の条件を全て満たす場合、認証要求(AuthnRequest)の署名検証時に確率的に問題が発生することが確認されています。IdPのバグで、2.4.0で修正されました。SPメタデータに記載されている不要な証明書を削除することにより回避可能です。
詳細: https://issues.shibboleth.net/jira/browse/JXT-99

1. IdPがJava 7を使用している。
2. 接続しようとしているSPのメタデータに1024bitの証明書と2048bitの証明書が混在している。
3. SPが認証要求(AuthnRequest)に署名している。

$ sudo -u tomcat /opt/shibboleth-idp/bin/aacli.sh --configDir /opt/shibboleth-idp/conf/ --principal=test001 --requester=https://sp.example.ac.jp/shibboleth-sp
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.HandlerManager': Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: javax/servlet/ServletRequest
       at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480)
                    :

→ 上記エラーが出力された場合はTomcatのjarファイルを参照するようにしてください。

$ sudo ln -s $CATALINA_HOME/lib/servlet-api.jar /opt/shibboleth-idp/lib/

→ aacli.shコマンドの詳細は 設定・運用・カスタマイズ > SPに対してどのような属性が送出されるか確認する方法 と https://wiki.shibboleth.net/confluence/display/SHIB2/AACLI をご参照ください。
→ 参考情報 : 情報交換メーリングリストupki-fed:00419

例え学認の「メタデータ記載の証明書更新手順（SP）」に倣ってSPが慎重に証明書更新を行っている場合でも、SPメタデータとして /Shibboleth.sso/Metadata を参照している限り発生する可能性があります。以下でその理由をステップバイステップで見ていきます。

1. メタデータ記載の証明書更新手順（SP） の「1日目　 SPに対して設定変更1（新証明書を暗号化用として追加）」をSPで実施すると、「.../Shibboleth.sso/Metadata」からダウンロードできるSPメタデータにも新しい証明書が追加されます。新しいメタデータはShibboleth SPの設定に従ってKeyDescriptorに use="encryption" という暗号化用途のみで利用するための設定が追加されます。

   SPの設定	SPが自動生成するメタデータ	⇒伝播中⇒	IdPのローカルに配置したメタデータ
   旧証明書 : 署名&暗号化用途 新証明書 : 暗号化用途	旧証明書 : use指定なし 新証明書 : use="encryption"		旧証明書 : use指定なし

2. SP管理者からの通知に従い、IdP管理者はSPが自動生成するファイルを取得してIdPのローカルにあるメタデータを更新します。

   学認に参加しているSPでは メタデータ記載の証明書更新手順（SP） の「X日目　 承認、学認メタデータに反映」に該当する部分です。

   SPの設定	SPが自動生成するメタデータ	=伝播済=	IdPのローカルに配置したメタデータ
   旧証明書 : 署名&暗号化用途 新証明書 : 暗号化用途	旧証明書 : use指定なし 新証明書 : use="encryption"		旧証明書 : use指定なし 新証明書 : use="encryption"

3. メタデータ記載の証明書更新手順（SP） の「X+15日目　SPに対して設定変更2（新証明書をメインにし旧証明書を暗号化用に変更）」をSPで実施します。この瞬間、SPに設定された証明書の用途とIdPが想定する証明書の用途に不一致が発生してしまいます。つまりSPは設定通り署名用途として新証明書を使いますが、IdPは新証明書は暗号化用途のみに使えるものと考えているためにこれを受け付けません。IdPでローカルに配置したメタデータが更新されるまでの間この状態が続き、エラーとなることが考えられます。

   SPの設定	SPが自動生成するメタデータ	⇒伝播中⇒	IdPのローカルに配置したメタデータ
   旧証明書 : 暗号化用途 新証明書 : 署名&暗号化用途	旧証明書 : use="encryption" 新証明書 : use指定なし		旧証明書 : use指定なし 新証明書 : use="encryption"

4. その後「Y+15日目　SPに対して設定変更3（旧証明書削除）」でも問題が生じます。この時点で3.で自動生成されたメタデータがIdPのローカルに配置されていますが、これに暗号化用途の旧証明書が含まれているため、依然としてIdPは旧証明書を暗号化用途に用い、設定変更3が行われたSPではそれを復号できずにエラーとなります。このエラーもIdPでローカルに配置したメタデータが更新されるまで続くことになります。

   SPの設定	SPが自動生成するメタデータ	⇒伝播中⇒	IdPのローカルに配置したメタデータ
   旧証明書 : 不使用 新証明書 : 署名&暗号化用途	旧証明書 : 存在しない 新証明書 : use指定なし		旧証明書 : use="encryption" 新証明書 : use指定なし

→ この問題の原因はSPが自動生成したメタデータをそのままIdP側で利用することにあります。 2. において、IdPのローカルに配置するメタデータから新証明書のKeyDescriptorに設定されているuse属性を削除することで、SPの設定変更に影響を受けずにメタデータの更新を行うことができます。（useを指定しない場合は暗号化用途 (encryption) 、署名用途 (signing) のどちらにも利用できるため）
同様に、3.（設定変更2）の後でIdPのローカルに配置するメタデータからは旧証明書を削除しなければなりません。

→ 学認申請システムでは、上記でご紹介した手順と同じで メタデータ記載の証明書更新手順（SP） の「1日目　 学認申請システムにて証明書を追加（予備の欄に）」を行ったときには、新証明書のKeyDescriptorのuse属性は設定していません。もちろんX+15日目の旧証明書を削除する申請が承認された段階でSPメタデータから旧証明書が削除されます。

1. 対象のSPへアクセスし、DSを経由してIdPのログイン画面を表示します。
2. 末尾に記載した手順でJavaScriptを無効にします。
3. 続けてIdPで認証すると、SPにリダイレクトされるときに以下のページが表示されます。

   Note: Since your browser does not support JavaScript, you must press the Continue button once to proceed.

4. 右クリックで表示されるメニューから「ページのソースを表示する」を選択してください。「input type="hidden" name="SAMLResponse" ～」行の value の値がSAMLレスポンスとなります。
5. SAMLレスポンスの取得が完了したら、以下の手順の逆の操作を行い設定を元に戻してください。

Firefoxの場合は、以下の手順でJavaScriptを無効にできます。

1. アドレスバーに「about:config」を入力します。検索窓に「javascript.enabled」を入力すると現在の設定値が出てきますので、ダブルクリックしてtrueからfalseに変更します。

Internet Explorerの場合は、以下の手順でJavaScriptを無効にできます。

1. インターネットオプションから「セキュリティ」タブを開きます。
2. レベルのカスタマイズをクリックし、スクリプト > アクティブスクリプト で「無効にする」を選択後、OKをクリックします。

• 「a) 学認申請システムが生成したattribute-filterを直接読み込む方法」を採用している場合

  12:55:10.810 - WARN [org.opensaml.util.resource.ResourceChangeWatcher:168] - Resource https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxxJP?target=uapprovejp221 could not be accessed
  org.opensaml.util.resource.ResourceException: Unable to contact resource URL: https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxx?target=uapprovejp221
          at org.opensaml.util.resource.HttpResource.exists(HttpResource.java:94) ~[openws-1.4.4.jar:na]
          at org.opensaml.util.resource.FileBackedHttpResource.exists(FileBackedHttpResource.java:120) ~[openws-1.4.4.jar:na]
          at org.opensaml.util.resource.ResourceChangeWatcher.run(ResourceChangeWatcher.java:149) ~[openws-1.4.4.jar:na]
          at java.util.TimerThread.mainLoop(Timer.java:534) [na:1.6.0_22]
          at java.util.TimerThread.run(Timer.java:484) [na:1.6.0_22]
  Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
          at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.6.0_22]
          at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1697) ~[na:1.6.0_22]
          (...省略...)
  Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
          at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:324) ~[na:1.6.0_22]
          at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:224) ~[na:1.6.0_22]
          at sun.security.validator.Validator.validate(Validator.java:235) ~[na:1.6.0_22]
          at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:147) ~[na:1.6.0_22]
          at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:230) ~[na:1.6.0_22]
          at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:270) ~[na:1.6.0_22]
          at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1144) ~[na:1.6.0_22]
          ... 21 common frames omitted
  Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
          at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:197) ~[na:1.6.0_22]
          at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:255) ~[na:1.6.0_22]
          at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:319) ~[na:1.6.0_22]
          ... 27 common frames omitted

  → JDKのトラストアンカーに必要なCA証明書が入っていないことが原因です。「IdPのトラストアンカーの確認と必要なCA証明書の導入」にしたがって， パッケージのアップデート，またはCA証明書の導入を行ってください。

• 「b) 学認申請システムが生成したattribute-filterをローカルにダウンロードした上で読み込む方法」を採用している場合

  $ wget https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxxJP?target=uapprovejp221
  --2015-06-29 19:12:37--  https://office.gakunin.nii.ac.jp/ProdFed/export/attribute_filter/PIxxxxJP?target=uapprovejp221
  office.gakunin.nii.ac.jp をDNSに問いあわせています... 157.1.67.71
  office.gakunin.nii.ac.jp|157.1.67.71|:443 に接続しています... 接続しました。
  エラー: office.gakunin.nii.ac.jp の証明書(発行者: /C=JP/O=SECOM Trust Systems CO.,LTD./CN=SECOM Passport for Web EV 2.0 CA)の検証に失敗しました:
    発行者の権限を検証できませんでした。
  office.gakunin.nii.ac.jp に安全の確認をしないで接続するには、`--no-check-certificate' を使ってください。
  SSL による接続が確立できません。

  → wget等のコマンドが参照するトラストアンカーに必要なCA証明書が入っていないことが原因です。「SPのトラストアンカーの確認と必要なCA証明書の導入」にしたがって， パッケージのアップデート，またはCA証明書の導入を行ってください。SP向けの手順としてご紹介していますが，今回のようなIdPにおけるwgetコマンド等の対処でも手順は同じです。

opensaml::FatalProfileException
...
opensaml::FatalProfileExceptionat (https://sp.example.ac.jp/Shibboleth.sso/SAML2/POST)
A valid authentication statement was not found in the incoming message.

→SPメタデータに記載されている証明書がSPにインストールされていない。
加えて、SPメタデータに複数証明書が記載されており、その一部がインストールされていない場合、タイミングによってエラーになったりならなかったりするので特に注意が必要。

また、比較的最近構築されたIdPを用いている場合、IdPが利用する暗号アルゴリズムをSPがサポートしていない場合（例えば古いOS上でShibboleth SPを動作させている場合）にこのエラーが発生する場合があるようです。詳細およびIdP側での一時的対処方法は以下をご参照ください。
⇒SPにおけるAES-GCM暗号対応状況

    エラー: 無効なクエリです
    The return URL 'https://sp.example.ac.jp/Shibboleth.sso/DS' could not be verified for Service Provider 'https://sp.example.ac.jp/shibboleth-sp'.

→学認技術ガイドに従ってSPを設定した場合、DSからのリターンURLは 'https://HOSTNAME/Shibboleth.sso/DS' となります。学認申請システムでSPの登録を行なうときに「DSからのリターンURL 」項目がこの値になっていない場合には上記のエラーが表示されます。

→なお、学認技術ガイドの「２．DSサーバの参照設定を行います。」において、SessionInitiatorのLocationを変更した場合にはDSからのリターンURLも変わります。例えば <SessionInitiator type="Chaining" Location="/ABC"...> としたときのDSからのリターンURLは 'https://HOSTNAME/Shibboleth.sso/ABC' となります。また、shibboleth2.xmlにSessionInitiatorが1つも存在しない場合にはデフォルト値の 'https://HOSTNAME/Shibboleth.sso/Login' を使用してください。

エラー: 無効なクエリです
リターンURL 'https://sp.example.ac.jp/Shibboleth.sso/DS' はSP 'https://SP.example.ac.jp/shibboleth-sp' のものとみなされません

→ 例えば、学認申請システムにentityIDを「https://SP.example.ac.jp/shibboleth-sp」（ホスト部の SP だけが大文字）のように登録したときにDSでこのようなエラーが発生します。DSでは大文字・小文字を区別して動作しますが、DNSにおいてホスト名は大文字・小文字を区別しないことが一般的です。利用する環境によっては大文字のホスト名が自動的に小文字で処理されることがあり、エラーとなります。エラー画面が表示されているときのアドレスバーに注目しますと、 return= から始まる部分が自動的に小文字となってしまっていることが確認できると思います。

https://test-ds.gakunin.nii.ac.jp/WAYF?entityID=https%3A%2F%2FSP.example.ac.jp%2Fshibboleth-sp&return=https%3A%2F%2Fsp.example.ac.jp%2FShibboleth.sso%2F...

2012-11-16 17:45:00 ERROR Shibboleth.AttributeResolver.Query [6]: exception during SAML query to https://idp.example.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery: CURLSOAPTransport failed while contacting SOAP endpoint (https://idp.example.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery): connect() timed out!
2012-11-16 17:45:00 ERROR Shibboleth.AttributeResolver.Query [6]: unable to obtain a SAML response from attribute authority

→上記のエラーはIdP(idp.example.ac.jp)のattribute-filter.xmlに接続元SPへの属性送出設定がない(属性が受け渡されない)とき、SAML2でBack-Channelポートにfallbackするため発生します。IdP側のファイアウォールなどでBack-Channel(ポート8443)への接続が許可されていない場合にタイムアウトとなることがあります。いずれにしろ設定により属性は渡されませんので、このエラーによる実害は（ブラウザ表示の遅延以外は）特にありません。
→SAML2対応IdPのみ接続するときに「SPでBack-Channelを使用しないようにする設定」を以下に記載します。学認外のIdPと連携する場合など、SAML1で属性受け渡しをする可能性があるときは属性取得できなくなりますので、SAML2でかつBack-Channelを利用しないときだけに用いてください。

• /etc/shibboleth/shibboleth2.xml で次の部分をコメントアウト

          <!-- Use a SAML query if no attributes are supplied during SSO. -->
        <!--
        <AttributeResolver type="Query" subjectMatch="true"/>
        -->

$ sudo /etc/init.d/shibd start
Starting shibd: configuration is invalid, check console for specific problems
                                                           [FAILED]

また /var/log/shibboleth/shibd.log には下記のエラーが出力されています。

2013-02-12 14:36:06 ERROR XMLTooling.ParserPool : fatal error on line 105, column 145, message: expected entity name for reference
2013-02-12 14:36:06 ERROR Shibboleth.Config : error while loading resource (/etc/shibboleth/shibboleth2.xml): XML error(s) during parsing, check log for specifics
2013-02-12 14:36:06 FATAL Shibboleth.Config : caught exception while loading configuration: XML error(s) during parsing, check log for specifics

→上記のエラーは shibboleth2.xml にXML文法としての間違いがある場合に出力されます。
→例えばCredentialResolverにパスフレーズ付きの証明書を設定するとき、パスフレーズに '&' や '<' を含む場合はこれらの文字列をそのまま設定することはできません。これらの文字を含む場合は文字参照で & や < のように記述してください。

• 誤ったパスフレーズ設定例

  <CredentialResolver type="File" key="cert/server-enc.key" certificate="cert/server-enc.crt" password="myKeyPa$$word&"/>

• 正しいパスフレーズ設定例

  <CredentialResolver type="File" key="cert/server-enc.key" certificate="cert/server-enc.crt" password="myKeyPa$$word&amp;"/>