JSignPDF says "Empty input" when CRL server redirects http requests to https

[NextTherapist]

I think I found the reason for my difficulties to get an LTV signature in an architecture with an intermediate certificate, see here:
#46 (comment)

My old intermediate certificate had a CRL distribution point beginning with http://...
When signing, I became the error message (in german)

INFORMATION Lade CRL von http://www....root_ca.crl herunter
WARNUNG
java.security.cert.CRLException: Empty input
at java.base/sun.security.provider.X509Factory.engineGenerateCRL(Unknown Source)
at java.base/java.security.cert.CertificateFactory.generateCRL(Unknown Source)
at net.sf.jsignpdf.crl.CRLInfo.initCrls(CRLInfo.java:130)
at net.sf.jsignpdf.crl.CRLInfo.getByteCount(CRLInfo.java:104)
at net.sf.jsignpdf.SignerLogic.signFile(SignerLogic.java:358)
at net.sf.jsignpdf.Signer.signFiles(Signer.java:246)
at net.sf.jsignpdf.Signer.main(Signer.java:139)

The reason seems to be the following redirection for http addresses to https, done by my server's .htaccess file with

    RewriteEngine On
	RewriteCond %{HTTPS} off [OR]
	RewriteCond %{HTTP_HOST} !^www\. [NC]
	RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
	RewriteRule ^ https://www.%1%{REQUEST_URI} [L,NE,R=301]

These days I generated a new intermediate certificate and changed the distribution point URL to https://...
And now I suddenly get LTV signatures without hazzle.

I do not know if this has its origin in JSignPDF or in Java (I use Java 21 JRE 64 bit in Windows 11), but it is actually not recommended to have https links in certificates because a circular argument could appear when using the certificates for SSL purposes. Other software like Adobe Acrobat Reader is resilient with http URL and downloads the CRL without a problem. It seems to follow the redirection.