Problem with R3 expired

Help
1

Hi,
I have an emby server running on an ubuntu 20.04 server with a letsencrypt ssl certificate. It runs for years without problems, but since the expiration of the R3 certificate my android devices can't connect anymore.

I used certbot to generate a new certificate with the following command:
sudo certbot certonly --standalone -d mydomain.com
then I converted the pem to pfx with this command:
sudo openssl pkcs12 -inkey /etc/letsencrypt/live/mydomain.com/privkey.pem -in /etc/letsencrypt/live/mydomain.com/fullchain.pem -export -out /var/lib/emby/ssl/emby.pfx
sudo service emby restart

If I test my ssl with this link: SSL Checker
it shows the Certificate #2 is the expired one.

image
image976Ă—608 39.2 KB

Am I doing something wrong?

Thanks for your help.

2 Likes
2

I also tried the following commands:
sudo dpkg-reconfigure ca-certificates
and:
update-ca-certificates
with no success

1 Like
3

There seems to be a wider impact because of this. Here are two threads on google chrome:
https://support.google.com/chrome/thread/128645073/google-chrome-flags-my-colleges-website-as-“insecure”-and-won’t-let-me-access-it-how-do-i-stop-it
https://support.google.com/chrome/thread/128685561/your-connection-is-not-private-notification?hl=en

Folks with older apple mac devices (Yosemite & El Captan) are getting errors. The correct recourse is to update their systems to install the updated root certificates.

For clarification - this is the root certificate on the client operating system, not the server. Updating let's encrypt certificate on the server won't fix it.

1 Like
4

With Chrome I can access to my server.
With my smartphone too.
But I can't with my Nvidia Shield, whose Android version is not so old.

1 Like
5

Hi @TuXFire welcome to the LE community forum :slight_smile:

That is expected.

Not that I can see.
But you haven't shown the FQDN, so there is no real way to confirm/deny your settings.
[other than the snippet shown from SSL Checker]

There are other, more detailed, tools that can be used.
Or you could show more than just the one "error line" from their report.
It may be difficult to understand, but pointing to the error only doesn't usually tell us enough about how one got there.

1 Like
6

The FQDN is valthorens59.ddns.net

Is the problem server related or client (Nvidia Shield) related?

1 Like
7

Server related. Your server is sending an ANCIENT certificate chain:

Certificate chain
 0 s:CN = valthorens59.ddns.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

The intermediate send (nr "1" above) has been deprecated for a long time now and has expired.

So either your fullchain.pem is incorrect for some reason or your emby server isn't picking up the pfx in the correct way.

2 Likes
8

So what can I do to resolve that?
My commands in the first post aren't correct?

1 Like
9

The command to generate the pfx seems to be correct. I just tested and my pfx got all the intermediate certs included too. You can check by running:

openssl pkcs12 -info -nokeys -in /var/lib/emby/ssl/emby.pfx

It should output the entire contents of the pfx without the private key.

2 Likes
10 
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
    localKeyID: 9B 96 3A 24 A7 0B 47 B6 B6 3D A9 C9 23 62 D9 A7 77 BF 4F A2 
subject=CN = valthorens59.ddns.net

issuer=C = US, O = Let's Encrypt, CN = R3

-----BEGIN CERTIFICATE-----
MIIFLzCCBBegAwIBAgISA+oIVunQ7aVa88OXBUV4s7KbMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMDMxMDMxMjJaFw0yMjAxMDExMDMxMjFaMCAxHjAcBgNVBAMT
FXZhbHRob3JlbnM1OS5kZG5zLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAMX6oROz771JCVwKKTpssK7WyqsCYIu2U7VPEeL0Ya4sL202XlVjeQGr
7mWPf2AE511HsnaIPu/iu8x32coeUjmCjrrme7f9ByeGPRQlSpAuIiJuGnPSO059
Ptc4oT9Hz7dGC5nPx/BNumCx2C/KOQhLqoocsYB+8P6sRfdPVWPf6aHWBDJeYbCC
6G9nW0HZBWUKwHoI2tskDbH6oFNjnAgiv4/kzFn4/tsnO3N83dPIrTDqZP7uxYuK
hWFgxCdWNuuwwWqAKmUdGJXa2ADOR9QUovLKx4apKD3HVYPurWbJlvyNbzp9E+vp
w87naEtencUEovyISR5LjkPwaGwPrPMCAwEAAaOCAk8wggJLMA4GA1UdDwEB/wQE
AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIw
ADAdBgNVHQ4EFgQUuN/Zj9qTbQBhj17PHFbo7XjEWVowHwYDVR0jBBgwFoAUFC6z
F7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVo
dHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxl
bmNyLm9yZy8wIAYDVR0RBBkwF4IVdmFsdGhvcmVuczU5LmRkbnMubmV0MEwGA1Ud
IARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0
dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDv
AHUAQcjKsd8iRkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAF8Rew/UAAABAMA
RjBEAiArqG6mi800Yun9C9o2G8V85V1Zo9fPPphNg688rBMAhgIgb79vwAopzl+I
YDaJcXFmtvlz8ATa8N5RrT+mBGVY5ZoAdgBGpVXrdfqRIDC1oolp9PN9ESxBdL79
SbiFq/L8cP5tRwAAAXxF7D90AAAEAwBHMEUCIHIzagEPggoMm/7QmBOiBUq/8Ghk
JbqyikrmgpISmPUAAiEAtNPcwSVGxtp2Nad77WYvx/9x/UaK4iWfPNHNvDQeLXsw
DQYJKoZIhvcNAQELBQADggEBAHitxSVWy/C0cdgEIRE6CXG49smnioY5zK7qowh1
pi4nHfMzWcfDJkzDmN3FU+xGEyciw/wBDImVU0HdmzzuCzzMr3O70efUXtG57YKG
3Elo6KHAcsQo4eQWIU8ocPHfv2sJ4mLOLZvQZtOju12NFpePQEj8M5+kp+Pmclsp
nS6jBo8KGmH+S8dO90xrqPhelVq6wb9NUkSDiqjoHth+QzPOQ3ySgGLKDh0Qx18n
dts4HtHRWxSLoGeQEU6AQd/9Qx58XFTGyUiHeH1HLfyn9bEs2y/T7tTxp67rAtQW
OC4Claa1bk5y7CYN2yzvuN8Qjdl77VpB50JjyKGC1XfYeCU=
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=C = US, O = Let's Encrypt, CN = R3

issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
1 Like
11

@TuXFire
The certs shown are not the ones being served:

openssl s_client -connect valthorens59.ddns.net:443 -servername valthorens59.ddns.net
CONNECTED(00000005)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:CN = valthorens59.ddns.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
1 Like
12

don't you have the command backwards, wouldn't it be:

openssl pkcs12 -inkey /etc/letsencrypt/live/mydomain.com/fullchain.pem -in /etc/letsencrypt/live/mydomain.com/privkey.pem -export -out /var/lib/emby/ssl/emby.pfx

see

1 Like
13

-inkey needs the private key - not the public cert/chain.
I'd say: NO

1 Like
14

@Ted probably meant to also switch the -inkey and -in sequence :wink:

1 Like
15

So my command is wrong? What shoud I type?
sudo openssl pkcs12 -in /etc/letsencrypt/live/mydomain.com/fullchain.pem -inkey /etc/letsencrypt/live/mydomain.com/privkey.pem -export -out /var/lib/emby/ssl/emby.pfx
is that correct?

1 Like
16

I'm not sure if it'll make any difference, but that's what @Ted meant I think indeed.

The same files will be included in the PFX, but probably just in a different order.

I also saw that the pkcs12 function has a -chain option, so maybe you need to feed it cert.pem using -in and feed it chain.pem using -chain. No idea if that makes the PFX any different, but maybe Emby is very picky about how the chain is presented to it..

Probably worth trying both..

Also, it's very weird: if the PFX does not contain the already expired R3-signed-by -DST Root CA X3, where did it come from? Does Emby have it cached somewhere? It didn't come from the PFX you've shown..

2 Likes
17

I have absolutly no idea.

18

I'm afraid i'm a bit lost..
If i sumirize well the situation:

  • My .pem certificates (fullchain.pem, privkey.pem) are good
  • My .pfx is good (does not contain the already expired R3-signed-by -DST Root CA X3)
  • The expired R3-signed-by -DST Root CA X3 comes from somewhere else
19

@TuXFire
I'm more than happy to walk through all that to confirm it and help figure out where the problem is with you.
In order for me to do that, I would need:

  • the FQDN that is serving the .pem/.pfx files
  • a picture of the error message (pictures paint a thousand words)
  • any relevant details about the client that is having trouble (the client from the picture)
20

@rg305
In fact I'm administrating 2 servers with the same configuration (ubuntu 20.04 server running emby, with a let's encrypt certificate) facing the same issue.

  • the FQDN of the 2 servers are valthorens59.ddns.net & tuxfire.ddns.net

  • It worked flawlessly for years but since the expiration of the certificate on 09/29 I can't access them anymore from my Nvidia Shield's emby app. (I can access localy with local IP/http, but not from outside with FQDN https. It says that the server is unreachable and is probably down but doesnt give more details. I installed a (very basic) browser on the Shield and tested the url, but it said "404" in full screen and nothing more.
    I can access via web browser from a PC or via the Android Smartphone app without problem.