トラブルシューティング
- 1 IdP関連
- 1.1 IdP起動時のエラー(The entity name must immediately follow the '&' in the entity reference)
- 1.2 IdP起動時のエラー (javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null)
- 1.3 IdPで認証前にブラウザにエラー(SAML 2 SSO profile is not configured for relying party)
- 1.4 IdPで認証時にブラウザにエラー(Message was signed, but signature could not be verified)
- 1.5 IdPで認証時にブラウザにエラー(Message expired, was issued too long ago)
- 1.6 IdPにエラー(net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException: No entries returned from search)
- 1.7 IdPで認証時にエラー
- 1.8 IdPで認証時のエラーにより再ログインが要求される (Exception unwrapping data: Tag mismatch!)
- 1.9 IdPで認証時にTomcatのエラー
- 1.10 Tomcat 6.0.43およびそれ以降でのBack-Channel接続のエラー
- 1.11 JDK 8u60 , 8u51 , 7u85 , 6u101でのメタデータ取得エラー
- 1.12 attribute-filter.xmlに属性を送信するように設定しているはずなのに送信されない。
- 1.13 2.3.8もしくはそれ以前のIdPで認証前にログにエラー
- 1.14 aacli.shが実行できない問題の対処(その1)
- 1.15 aacli.shが実行できない問題の対処(その2)
- 1.16 ローカルに配置したSPメタデータの証明書更新時のエラー
- 1.17 SAMLレスポンスを取得する方法
- 1.18 学認申請システムが自動生成するattribute-filter取得時のエラー
- 2 SP関連
IdP関連
IdP起動時のエラー(The entity name must immediately follow the '&' in the entity reference)
IdPを起動時に下記のエラーが idp-process.log に出力されます。
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&">/opt/shibboleth-idp/credentials/server-enc.key</security:PrivateKey>
これはXML形式の表記上の問題ですので、relying-party.xmlに限らず全ての設定ファイルが対象となります。例えばattribute-resolver.xmlのLDAPのパスワード(principalCredential)も同様です。
IdP起動時のエラー (javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null)
IdP起動時のメタデータ取得に際し、下記のエラーが idp-process.log に出力されます。
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のサポートをご検討ください。
IdPで認証前にブラウザにエラー(SAML 2 SSO profile is not configured for relying party)
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が最新のメタデータ取得に失敗している可能性があります。
IdPで認証時にブラウザにエラー(Message was signed, but signature could not be verified)
Shibboleth認証時にブラウザに下記のエラーが出力されます。
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) をご参照ください。
IdPで認証時にブラウザにエラー(Message expired, was issued too long ago)
Shibboleth認証時にブラウザに下記のエラーが出力されます。
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にエラー(net.shibboleth.idp.attribute.resolver.NoResultAnErrorResolutionException: No entries returned from search)
IdPで認証時にエラー
→ IdPが運用フェデレーションとテストフェデレーションの双方に同一のentityIDで参加している場合に、認証エラーとなることがあります。これはテストフェデレーション側のメタデータに掲載されている証明書情報が誤って取り込まれることが原因と推定されています。テストフェデレーション側のIdPについて実運用のIdPと異なるentityIDを利用するなどし、テストフェデレーション側のIdPは廃止申請すると問題の切り分けが行いやすくなります。
→ 関連して、運用フェデレーションで実運用中のIdPにおいて、テストフェデレーションのメタデータを読み込んでいる場合には、テストフェデレーションのメタデータ読み込み設定を削除してください。運用フェデレーションのメタデータのみを読み込む設定としたほうがより原因を追究しやすい状態となります。
→ transientIdが必須となっているSPにおいて、IdP側でtransientIdの送出が制限されている場合にエラーとなる場合があります。要求されている属性が正しく送出されているにも関わらず認証エラーとなる場合にはtransientIdの送出の有無を確認しておくと問題の切り分けに役立ちます。
→ SPが要求している属性と異なる属性を送出している場合にもエラーとなります。学認のIdP・SP一覧(https://www.gakunin.jp/participants/)で指定されている属性とattribute-filter.xmlの設定が一致しているか見直してください。attribute-filter.xmlを設定後、 設定・運用・カスタマイズ#SPに対してどのような属性が送出されるか確認する方法 の手順で実際に送出される属性を確認することができます。特に「eduPersonAffiliation (スコープなし)」と「eduPersonScopedAffiliation (スコープあり)」は似ていることもあり、間違えやすいことから注意が必要です。
IdPで認証時のエラーにより再ログインが要求される (Exception unwrapping data: Tag mismatch!)
IdPでログイン済みなのにSSOせず、下記のエラーが idp-process.log に出力されて、再度ログイン画面が表示されます。
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.*
IdPで認証時にTomcatのエラー
Shibboleth認証時にブラウザに503エラーが出力され、Tomcatに下記のログが出力されます。
[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] でも同様の問題が発生していたとの報告があります。