AlmaLinux9のOpenSSL/3.0.7でレガシーアルゴリズムを使用したい（Android決済レシートの検証）

本題

AlmaLinux9環境でAndroidの決済レシートの検証処理が成功しない

状況

AlmaLinux8のOpenSSL/1.1.1kの環境下で

php
1$result = openssl_verify($receipt, $signature, $key, OPENSSL_ALGO_SHA1)

を実行すると問題なく実行でき、$resultは 1（＝検証成功） となるのですが、
AlmaLinux9のOpenSSL/3.0.7の環境下で完全に同じソースを実行すると
$resultは -1（＝エラー） になります。

openssl_error_string()を使用してエラーの内容を確認したところ、

openssl_error_string
1error:0480006C:PEM routines::no start line
2error:03000098:digital envelope routines::invalid digest

とありました。
※PEMなどの内容はAlmaLinux8環境で成功するものとまったく同じものとなっており、
環境差による結果の差異を考慮しなくて良いように値はすべてリテラルな文字列で定義しています。

OPENSSL_ALGO_SHA1 を OPENSSL_ALGO_SHA256 に変えると
$resultは 0（＝検証失敗） となるので、

OPENSSL_ALGO_SHA1 ⇒ 非推奨のレガシーアルゴリズムのため検証処理の実行に失敗
OPENSSL_ALGO_SHA256 ⇒ レシートはSHA1が採用されているため、検証した結果、不一致

という状況にあるものと認識しております。

実行環境はPHP8.1.29です。

/etc/ssl/openssl.cnf を

openssl.cnf
1[provider_sect]
2legacy = legacy_sect
3
4[legacy_sect]
5activate = 1
6module = /usr/lib64/ossl-modules/legacy.so

とlegacy関連をコメントアウトし、
legacy.soへのパスを通すことでレガシーアルゴリズムが有効になるという記事があったので
こちらを設定し、phpinfo()で確認すると

PHPinfo
1MULTI_SSL	No
2SSL Version	OpenSSL/3.0.7
3libSSH Version	libssh/0.10.4/openssl/zlib
4
5openssl
6OpenSSL support	enabled
7OpenSSL Library Version	OpenSSL 3.0.7 1 Nov 2022
8OpenSSL Header Version	OpenSSL 3.0.7 1 Nov 2022
9Openssl default config	/etc/pki/tls/openssl.cnf
10Directive	Local Value	Master Value
11openssl.cafile	no value	no value
12openssl.capath	no value	no value
13
14$_SERVER['SERVER_SOFTWARE']	Apache/2.4.57 (AlmaLinux) OpenSSL/3.0.7 SVN/1.14.1
15
16OpenSSL	Stig Venaas, Wez Furlong, Sascha Kettler, Scott MacVicar, Eliot Lear

という表示となり、

shell
1openssl dgst -sha1 test.txt

とSHA1を使用しての処理が成功する状態になっているので
OpenSSLの設定としてはレガシーアルゴリズムの使用を有効にできているように見受けられるのですが、肝心の

php
1$result = openssl_verify($receipt, $signature, $key, OPENSSL_ALGO_SHA1)

が通らずに困っております。

追記

コメントにてご紹介いただいた記事にあった

shell
1update-crypto-policies --set DEFAULT:SHA1

を実行し、update-crypto-policies --show の結果が DEFAULT:SHA1 と表示される状況で動作確認をしてみましたが、結果は変わりませんでした。
--追記終了

そもそもSHA1で検証しようとしているのが間違いで、
「新しいエンドポイントにアクセスしてSHA256を採用したAndroidの決済レシートを受信する」など、
別の方法があったりするのでしょうか？

poto568

2024/07/17 05:57

https://zenn.dev/mingos/articles/04dfa99d0536b5 自分では試していませんが、似たような感じの問題を解決した記事がありました。参考になるかもしれません。

nija-yirak

2024/07/17 07:19 編集

コメントありがとうございます。ご紹介いただいた記事にあった update-crypto-policies --set DEFAULT:SHA1 を実行後に動作確認をしてみましたが、結果は変わりませんでした。

mingos

2024/07/17 09:22 編集

/etc/ssl/openssl.cnfの修正、 update-crypto-policies --set DEFAULT:SHA1 に加えて私の環境ではSELinuxを無効化しているのですが、それも関係あるかもしれません。しかしレシートの署名を検証する以外に、Google Play Developer APIを使用してアイテムの購入ステータスを確認する方法があります。現在ではこちらの使用が適切なのかもしれません。 https://developers.google.com/android-publisher?hl=ja https://developers.google.com/api-client-library?hl=ja

matukeso

2024/07/17 09:26

>/etc/ssl/openssl.cnf を >Openssl default config /etc/pki/tls/openssl.cnf これは同じファイルなんです？

mingos

2024/07/17 09:31

はい、それは同じファイルです。シンボリックリンクになってます。 $ ls -l /etc/ssl/openssl.cnf lrwxrwxrwx. 1 root root 24 Sep 13 2023 /etc/ssl/openssl.cnf -> /etc/pki/tls/openssl.cnf

nija-yirak

2024/07/17 10:20

> matukeso様細かい点のチェックありがとうございます。 > mingos様補足ありがとうございます。 sestatus の結果は SELinux status: disabled とこちらの環境もSELinuxが無効な状態でした。いずれSHA1を使用すること自体が難しい状況になり、 googleがレシートの作りをSHA256などに対応させるタイミングが来た際に「SHA256で確認→失敗した場合にSHA1で確認」という手順でも踏ませたりでもするのだろうか？という疑問があったのですが、ご紹介いただいた「APIで確認する方法へ切り替えるようアナウンスされる」という流れになるのは非常に合点がいきます。一番解決したい問題自体は「レシートを正しく検証したい」ということなのでご紹介いただいたAPIを使って確認する方法で対処できないか検討してみます。