Re: Can't display the certificate: Not found or the certificate is a bundle!
On Tue, Nov 14, 2023 at 02:21:44PM +0100, Christoph Kukulies wrote: > Thanks. > > I did a fresh > > acme.sh --issue -d domain ... --keylength 2048 > with prior revoking the certificates since I was a bit unsure what the > partially exposing of my provate key was concerned - thanks, Shawn. > > I went back to the Wiki and found the necessary steps there: > > DEPLOY_HAPROXY_HOT_UPDATE=yes > DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock > DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d > www.mydomain.org --deploy-hook haproxy > [Tue Nov 14 02:07:26 PM CET 2023] Deploying PEM file > [Tue Nov 14 02:07:26 PM CET 2023] Moving new certificate into place > [Tue Nov 14 02:07:26 PM CET 2023] Reload successful > [Tue Nov 14 02:07:26 PM CET 2023] Success > acme@mail:~/.acme.sh$ ls -l /etc/haproxy/certs > total 12 > -rw-rw-r-- 1 acme acme 8489 Nov 14 14:07 www.mydomain.org.pem > > Christoph Kukulies > k...@kukulies.org > > > > This file seems to be assembled by the deploy script. (since it contains the > private key). > > So far so good for the first. Got to implement the renewal mechanism now. I don't think you followed correctly the instruction of the wiki, the DEPLOY_HAPROXY_HOT_UPDATE=yes option is supposed to prevent the reload by using the CLI. It does not look like this is working here. You must have skipped the installation of the deploy script. https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh#acmesh-installation -- William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
Thanks. I did a fresh acme.sh --issue -d domain ... --keylength 2048 with prior revoking the certificates since I was a bit unsure what the partially exposing of my provate key was concerned - thanks, Shawn. I went back to the Wiki and found the necessary steps there: DEPLOY_HAPROXY_HOT_UPDATE=yes DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d www.mydomain.org --deploy-hook haproxy [Tue Nov 14 02:07:26 PM CET 2023] Deploying PEM file [Tue Nov 14 02:07:26 PM CET 2023] Moving new certificate into place [Tue Nov 14 02:07:26 PM CET 2023] Reload successful [Tue Nov 14 02:07:26 PM CET 2023] Success acme@mail:~/.acme.sh$ ls -l /etc/haproxy/certs total 12 -rw-rw-r-- 1 acme acme 8489 Nov 14 14:07 www.mydomain.org.pem Christoph Kukulies k...@kukulies.org This file seems to be assembled by the deploy script. (since it contains the private key). So far so good for the first. Got to implement the renewal mechanism now. > Am 13.11.2023 um 17:20 schrieb William Lallemand : > > On Mon, Nov 13, 2023 at 10:46:08AM +0100, Christoph Kukulies wrote: >>> Am 13.11.2023 um 10:09 schrieb William Lallemand : acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | socat /var/run/haproxy/admin.sock - Can't display the certificate: Not found or the certificate is a bundle! >> >> acme@mail:~/.acme.sh/www.mydomain.org_ecc$ echo "show ssl cert " | socat >> /var/run/haproxy/admin.sock - >> # filename >> /etc/haproxy/certs/fullchain.pem >> /etc/haproxy/certs/fullchain_ec.pem >>> >> > > Well, you can't display /etc/haproxy/certs/mydomain.org.pem because it's > not in haproxy. > > Can you share the output of your deploy acme.sh command as well as your > haproxy configuration? > > -- > William Lallemand -- Christoph smime.p7s Description: S/MIME cryptographic signature
Re: Can't display the certificate: Not found or the certificate is a bundle!
On Mon, Nov 13, 2023 at 10:46:08AM +0100, Christoph Kukulies wrote: > > Am 13.11.2023 um 10:09 schrieb William Lallemand : > >> > >> acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | > >> socat /var/run/haproxy/admin.sock - > >> Can't display the certificate: Not found or the certificate is a bundle! > >> > > acme@mail:~/.acme.sh/www.mydomain.org_ecc$ echo "show ssl cert " | socat > /var/run/haproxy/admin.sock - > # filename > /etc/haproxy/certs/fullchain.pem > /etc/haproxy/certs/fullchain_ec.pem > > > Well, you can't display /etc/haproxy/certs/mydomain.org.pem because it's not in haproxy. Can you share the output of your deploy acme.sh command as well as your haproxy configuration? -- William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
On 11/13/23 02:09, William Lallemand wrote: "show ssl cert" shows the certificate in the haproxy memory, and not on the filesystem. Start by doing "show ssl cert" without any argument to see the list of certificates whcih were loaded by haproxy. That makes complete sense now! I saw an error on the other file because that file was not loaded by haproxy. I have never looked at the documentation for this so I do not know if that is complete enough ... but there is an opportunity for an improved error message here. Seems like haproxy would be able to detect that the requested file is not loaded into memory and inform the user. Thanks, Shawn
Re: Can't display the certificate: Not found or the certificate is a bundle!
> Am 13.11.2023 um 10:09 schrieb William Lallemand : > > On Sat, Nov 11, 2023 at 10:26:33AM +0100, Christoph Kukulies wrote: >> I'm using haproxy2.8 and I have configured the acme.sh challenge to fetch >> the certificate, following this wiki here: >> https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh >> >> Once I get to the point to test the certificate, I'm getting: >> >> acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | >> socat /var/run/haproxy/admin.sock - >> Can't display the certificate: Not found or the certificate is a bundle! >> >> >> The file is definitely there and the command works an a different file, when >> I apply it to the previously used certificate fullchain.pem. >> The file which is not working, has the following structure: > > "show ssl cert" shows the certificate in the haproxy memory, and not on > the filesystem. Start by doing "show ssl cert" without any argument to > see the list of certificates whcih were loaded by haproxy. > Thanks, William, acme@mail:~/.acme.sh/www.mydomain.org_ecc$ echo "show ssl cert " | socat /var/run/haproxy/admin.sock - # filename /etc/haproxy/certs/fullchain.pem /etc/haproxy/certs/fullchain_ec.pem > And, Shawn, you may be right that it is not the ECC type itself causing the "Can't display" message but some other quirk. The funny thing: at the moment I cannot reproduce the issue at all. And the fullchain_ec.pem has "-BEGIN EC PRIVATE KEY-" and the corresponding END EC line in it. Will keep an eye on it next time. -- Christoph smime.p7s Description: S/MIME cryptographic signature
Re: Can't display the certificate: Not found or the certificate is a bundle!
On Sat, Nov 11, 2023 at 10:26:33AM +0100, Christoph Kukulies wrote: > I'm using haproxy2.8 and I have configured the acme.sh challenge to fetch > the certificate, following this wiki here: > https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh > > Once I get to the point to test the certificate, I'm getting: > > acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | socat > /var/run/haproxy/admin.sock - > Can't display the certificate: Not found or the certificate is a bundle! > > > The file is definitely there and the command works an a different file, when > I apply it to the previously used certificate fullchain.pem. > The file which is not working, has the following structure: "show ssl cert" shows the certificate in the haproxy memory, and not on the filesystem. Start by doing "show ssl cert" without any argument to see the list of certificates whcih were loaded by haproxy. -- William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
On 11/12/2023 02:37, Christoph Kukulies wrote: what the inadvertently publicly dislosing my private key is concerned: I obfuscated the excerpts of my .pem file by putting XX into the string. Destroying part of it would suffice, I think. Up to you. I wouldn't trust it personally. What the actual issue is concerned: It looks like haproxy (2.8) can't cope with the type of the certificate. An ECC (256 bit) seems to be generated by the acme.sh challenge by default. My certificate is also using 256 bit EC keys because that's what recent versions of Lets Encrypt certbot provide by default, but my PEM file does not actually say "EC" like yours does, and haproxy works with it perfectly, including the "show" command with the socket. The weird problem with the file on a tmpfs filesystem is probably unrelated. This is the line in /etc/fstab that creates the filesystem for /tmp: tmpfs /tmp tmpfs size=4096m,mode=1777 0 1 Another test with interesting results: I made a copy of the cert with identical permissions (in the same directory) and made one change: I changed "-BEGIN PRIVATE KEY-" and the matching END line to include the "EC" that yours has. With that change, I get the exact error that you are getting. I would bet that if you removed the "EC" from your PEM file, it would start working. My haproxy is compiled with the quictls fork of openssl, version 3.1.4. Thanks, Shawn
Re: Can't display the certificate: Not found or the certificate is a bundle!
Hi Shawn, what the inadvertently publicly dislosing my private key is concerned: I obfuscated the excerpts of my .pem file by putting XX into the string. Destroying part of it would suffice, I think. What the actual issue is concerned: It looks like haproxy (2.8) can't cope with the type of the certificate. An ECC (256 bit) seems to be generated by the acme.sh challenge by default. I changed the line for getting the certificate from acme.sh --issue -d www.domain1.org -d mail.domain1.org -d otherdomain.de -d mail.domain1.org -d imap.domain1.org -d smtp.domain1.org --stateless to: acme.sh --issue -d www.domain1.org -d mail.domain1.org -d otherdomain.de -d mail.domain1.org -d imap.domain1.org -d smtp.domain1.org --stateless --keylength 2048 That is, forcing a RSA 2048 certificate, and, wonder, this certificate worked. Now, what the glueing together of the fullchain.pem and the private key into one file is concerned: it woud be good if that can be avoided. I'm trying an approach now, to put a file fullchain.pem and fullchain.pem.key into the /etc/haproxy/certs directory and use bind *:443 ssl crt /etc/haproxy/certs/ strict-sni If anyone has a tip in that direction, I'd be grateful. > Am 11.11.2023 um 23:14 schrieb Shawn Heisey : > > On 11/11/2023 02:26, Christoph Kukulies wrote: >> The file is definitely there and the command works an a different file, when >> I apply it to the previously used certificate fullchain.pem. >> The file which is not working, has the following structure: >> -BEGIN EC PRIVATE KEY- > > I think you have just publicly disclosed the private key for your > certificate. If so, you should immediately replace that certificate with a > new one that uses a different key, and if it is a certificate generated by a > public CA, see about getting it revoked. > > On your issue: > > This is very strange. > > I ran your command with my LE certificate and it worked. > > echo "show ssl cert /etc/ssl/certs/local/elyograg_org.wildcards.combined.pem" > | socat /etc/haproxy/stats.socket - > > Then I made a copy of the certificate file as /tmp/fff/ddd and the same > command with that file returned the error you are getting! > > echo "show ssl cert /tmp/fff/ddd" | socat /etc/haproxy/stats.socket - > > The root filesystem is ext4 and /tmp is a tmpfs (ramdisk). Unix permissions > are not an issue, and I have never configured ACLs on this system. SELinux > is not active, and the apparmor service is stopped/disabled. It does look > like snapd has activated apparmor for snaps, which seems odd because the > service is stopped. > When using the acme.sh mechanism to obtain the cert apparmor and snapd/certbot wouldn't make sense in my situation, would they? > root@smeagol:/var/log# apparmor_status > apparmor module is loaded. > 59 profiles are loaded. > 54 profiles are in enforce mode. > /snap/snapd/20092/usr/lib/snapd/snap-confine > /snap/snapd/20092/usr/lib/snapd/snap-confine//mount-namespace-capture-helper > /snap/snapd/20290/usr/lib/snapd/snap-confine > /snap/snapd/20290/usr/lib/snapd/snap-confine//mount-namespace-capture-helper > docker-default > snap-update-ns.certbot > snap-update-ns.certbot-dns-route53 > snap-update-ns.chromium > snap-update-ns.crypto > snap-update-ns.cups > snap-update-ns.firefox > snap-update-ns.gradle > snap-update-ns.snap-store > snap.certbot-dns-route53.hook.post-refresh > snap.chromium.chromedriver > snap.chromium.chromium > snap.chromium.hook.configure > snap.crypto.crypto > snap.cups.accept > snap.cups.cancel > snap.cups.cups-browsed > snap.cups.cupsaccept > snap.cups.cupsctl > snap.cups.cupsd > snap.cups.cupsdisable > snap.cups.cupsenable > snap.cups.cupsfilter > snap.cups.cupsreject > snap.cups.cupstestppd > snap.cups.driverless > snap.cups.gs > snap.cups.ippeveprinter > snap.cups.ippfind > snap.cups.ipptool > snap.cups.lp > snap.cups.lpadmin > snap.cups.lpc > snap.cups.lpinfo > snap.cups.lpoptions > snap.cups.lpq > snap.cups.lpr > snap.cups.lprm > snap.cups.lpstat > snap.cups.reject > snap.firefox.firefox > snap.firefox.geckodriver > snap.firefox.hook.configure > snap.firefox.hook.connect-plug-host-hunspell > snap.firefox.hook.disconnect-plug-host-hunspell > snap.firefox.hook.post-refresh > snap.snap-store.hook.configure > snap.snap-store.snap-store > snap.snap-store.ubuntu-software > snap.snap-store.ubuntu-software-local-file > 5 profiles are in complain mode. > snap.certbot.certbot > snap.certbot.hook.configure > snap.certbot.hook.prepare-plug-plugin > snap.certbot.renew > snap.gradle.gradle > 0 profiles are in kill mode. > 0 profiles are in unconfined mode. > 0 processes have profiles defined. > 0 processes are in enforce mode. > 0 processes are in complain mode. > 0 processes are unconfined but have a profile defined. > 0 processes are in mixed mode. > 0 processes are in kill mode. > > Thanks, >
Re: Can't display the certificate: Not found or the certificate is a bundle!
On 11/11/2023 02:26, Christoph Kukulies wrote: The file is definitely there and the command works an a different file, when I apply it to the previously used certificate fullchain.pem. The file which is not working, has the following structure: -BEGIN EC PRIVATE KEY- I think you have just publicly disclosed the private key for your certificate. If so, you should immediately replace that certificate with a new one that uses a different key, and if it is a certificate generated by a public CA, see about getting it revoked. On your issue: This is very strange. I ran your command with my LE certificate and it worked. echo "show ssl cert /etc/ssl/certs/local/elyograg_org.wildcards.combined.pem" | socat /etc/haproxy/stats.socket - Then I made a copy of the certificate file as /tmp/fff/ddd and the same command with that file returned the error you are getting! echo "show ssl cert /tmp/fff/ddd" | socat /etc/haproxy/stats.socket - The root filesystem is ext4 and /tmp is a tmpfs (ramdisk). Unix permissions are not an issue, and I have never configured ACLs on this system. SELinux is not active, and the apparmor service is stopped/disabled. It does look like snapd has activated apparmor for snaps, which seems odd because the service is stopped. root@smeagol:/var/log# apparmor_status apparmor module is loaded. 59 profiles are loaded. 54 profiles are in enforce mode. /snap/snapd/20092/usr/lib/snapd/snap-confine /snap/snapd/20092/usr/lib/snapd/snap-confine//mount-namespace-capture-helper /snap/snapd/20290/usr/lib/snapd/snap-confine /snap/snapd/20290/usr/lib/snapd/snap-confine//mount-namespace-capture-helper docker-default snap-update-ns.certbot snap-update-ns.certbot-dns-route53 snap-update-ns.chromium snap-update-ns.crypto snap-update-ns.cups snap-update-ns.firefox snap-update-ns.gradle snap-update-ns.snap-store snap.certbot-dns-route53.hook.post-refresh snap.chromium.chromedriver snap.chromium.chromium snap.chromium.hook.configure snap.crypto.crypto snap.cups.accept snap.cups.cancel snap.cups.cups-browsed snap.cups.cupsaccept snap.cups.cupsctl snap.cups.cupsd snap.cups.cupsdisable snap.cups.cupsenable snap.cups.cupsfilter snap.cups.cupsreject snap.cups.cupstestppd snap.cups.driverless snap.cups.gs snap.cups.ippeveprinter snap.cups.ippfind snap.cups.ipptool snap.cups.lp snap.cups.lpadmin snap.cups.lpc snap.cups.lpinfo snap.cups.lpoptions snap.cups.lpq snap.cups.lpr snap.cups.lprm snap.cups.lpstat snap.cups.reject snap.firefox.firefox snap.firefox.geckodriver snap.firefox.hook.configure snap.firefox.hook.connect-plug-host-hunspell snap.firefox.hook.disconnect-plug-host-hunspell snap.firefox.hook.post-refresh snap.snap-store.hook.configure snap.snap-store.snap-store snap.snap-store.ubuntu-software snap.snap-store.ubuntu-software-local-file 5 profiles are in complain mode. snap.certbot.certbot snap.certbot.hook.configure snap.certbot.hook.prepare-plug-plugin snap.certbot.renew snap.gradle.gradle 0 profiles are in kill mode. 0 profiles are in unconfined mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. 0 processes are in mixed mode. 0 processes are in kill mode. Thanks, Shawn
Can't display the certificate: Not found or the certificate is a bundle!
I'm using haproxy2.8 and I have configured the acme.sh challenge to fetch the certificate, following this wiki here: https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh Once I get to the point to test the certificate, I'm getting: acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | socat /var/run/haproxy/admin.sock - Can't display the certificate: Not found or the certificate is a bundle! The file is definitely there and the command works an a different file, when I apply it to the previously used certificate fullchain.pem. The file which is not working, has the following structure: -BEGIN EC PRIVATE KEY- MHcCAQEEIHFXw2MqiGQUNIx6fHOZOqGs14BtPOpr1jeieJj43QxQoAoGCCqGSM49 AwEHoUQDQgAE0S6sFIR2+f0Vlw/2MaOv A6VSMz5YSLjKhvEqIyMhPCtKhDP07x57vQ== -END EC PRIVATE KEY- -BEGIN CERTIFICATE- XXXRAIgL6ZQa9Q9t0zDrSPrdDGAwCgYIKoZIzj0EAwMwSzEL MAkGA1UEBhMCQVQxEDAOBgNVBAoTB1plcm9TU0wxKjAoBgNVBAMTIVplcm9TU0wg IkTPzeuzhHbCcMIV+BXbljRngQ== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIDhTCCAwygAwIBAgIQI7dt48G7KxpRlh4I6rdk6DAKBggqhkjOPQQDAzCBiDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNl eSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT -END CERTIFICATE- -BEGIN CERTIFICATE- MIID0zCCArugAwIBAgIQVmcdBOpPmUxvEIFHWdJ1lDANBgkqhkiG9w0BAQwFADB7 MQswCQYDVQQGEwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE . CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEM BQADggEBABns652JLCALBIAdGN5CmXKZFjK9Dpx1WywV4ilAbe7/ctvbq5AfjJXy 8qn0dNW44bOwgeThpWOjzOoEeJBuv/c= -END CERTIFICATE- The file that is working, looks like this: -BEGIN CERTIFICATE- MIIFIjCCBAqgAwIBAgISBGJeRwzt+XStsqS4xbnbT6ObMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yMzEwMjMxNDIyMjlaFw0yNDAxMjExNDIyMjhaMBoxGDAWBgNVBAMT D25vcm1hbGZpbHRlci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMb9wrIs+zoN09SAK9A/Tl/wBGuRtC0CSsM/qIFi/kROF8tHrrltBFI5AUjlVVk/ AAOCAQEABoS6mLKw+PlkkVrMjM2es4nz+elgp/Qm4k0o2Da1B8QhxZkgzRioATcs P9yRSH6Xj3jBkpPvhml6jshmKqbDb46TAPERHc79Nx63RKWSZ3YEyyaYXOsa1i9O uWxzSkCFBSb8sMjMT9iNj+W7GoUMQQ== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh . yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+ HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX nLRbwHOoq7hHwg== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT . 5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW 9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5 -END CERTIFICATE- -BEGIN PRIVATE KEY- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDG/cKyLPs6DdPU gCvQP05f8ARrkbQtAkrDP6iBYv5EThfLR665bQRSOQFI5VVZP6iVeiql5s35FDUw Ha5FVepwzduMlwe1g68/CtFR2B7oH/+DGHFm+nglYeeEavqk547GwSPkmX5tPEEv . 8ZoxBPBJgBtDnrBO+JTf7ZygcQ5XTF03sSd2ytdjVlcTy+knlhBS3UIRq4ek2xs4 nNTNgxvFuuqSCIAFLVlSq9KDbHzlu96Xc7Cz4xVmtx2wwkf4OZkm912XRVv+xfDO rzuBSbjC9IthPoAPP3j8satO -END PRIVATE KEY- Maybe it's the ECC cert type/private key? Or the position of the private key? Clueless at the moment. -- Christoph smime.p7s Description: S/MIME cryptographic signature
