Still getting R3 certificates

Help
1

Hello,

I've tried multiple times to get a new certificate that doesn't use the old R3 key, but I just can't get it working. My setup requires me to have a .pfx file, so I run certbot to get a new certificate (or renew, both gave an old version) and then use an openssl command to convert them to a pfx file. But still I'm getting a certificate that makes use of the old DST Root CA X3 certificate. Can anyone help me to get a new certificate that works properly?

My domain is: arcticmanager.com

My web server is (include version): Ubuntu 16.04.5 LTS

The webserver is running on: Dotnet

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.22.0

1 Like
2

You say you're using Ubuntu, but your webservers Server header says it's Kestrel, which, as far as I can Google, is a Windows based service? I'm confused..

I don't have any experience with Kestrel or Windows based stuff, but for other volunteers seeing your thread it might help everybody what webserver you're actually using (you've removed that question from the questionnaire..) and which OS the service is running.

2 Likes
3

I'm sorry, I actually forgot to mention that, correct. The program that is running on the Ubuntu server is a dotnet program. I know it's not the moest convenient, but that's how I inherited this project, and it's too unstable to change. :sweat_smile:

1 Like
4

So to be clear: you're running an ASP.NET service which is using the Kestrel ASP.NET Core webserver implementation on an Ubuntu server using dotnet.

Well, the main question probably is: how is your ASP.NET service (i.e.: Kestrel) configured regarding TLS?

Also, the OpenSSL commands to generate your PFX would probably be helpful.

2 Likes
5

I guess so. I'm not gonna lie, I'm kinda lost with the system itself too. I'm hoping I'll be able to fix this without the need to recompile the program, because I'd need to spend hours to days trying to set up the old stuff... I know the program reads the cert file to use it, and when I renew it I just stop the program, renew the cert with certbot, create a new PFX and then restart the program.

I quickly looked in the repo, and this should hopefully answer that question:

                hostBuilder
                    .UseKestrel(options =>
                    {
                        options.Listen(IPAddress.Any, httpPort);
                        options.Listen(IPAddress.Any, sslConfig.ListenPort, listenOptions =>
                            {
                                var certificate = new X509Certificate2(sslConfig.CertPath, sslConfig.CertPass);
                                listenOptions.UseHttps(new HttpsConnectionAdapterOptions
                                {
                                    ServerCertificate = certificate,
                                    SslProtocols = System.Security.Authentication.SslProtocols.Tls12
                                });
                            });
                    });

openssl pkcs12 -export -out certificate.pfx -inkey privkey.pem -in fullchain.pem

1 Like
6

Why not put the whole thing behind an nginx reverse proxy?

1 Like
7

I would honestly have no idea where to start with that, and like I said previously, this is an old system I got this way. It'll take hours to days to even set up a proper local environment to even test such changes. I'm not actually properly familiar with dotnet / ASP.NET.

1 Like
8

Is the server behind a firewall/NAT device?

1 Like
9

No, it's being hosted on a vps/droplet on digitalocean.

1 Like
10

You need to look for the values of those two variables, sslConfig.CertPath and sslConfig.CertPass.

In which directory are you running that? Also, this suggests you haven't automated it, correct? You need to run it manually?

2 Likes
11 
	"Ssl":  {
		"ListenPort": 443,
		"CertPath": "/etc/letsencrypt/live/arcticmanager.com/certificate.pfx",
		"CertPass": "**********"
	},

Hidden the Pass for security reasons.

I'm running that in /etc/letsencrypt/live/arcticmanager.com/, and yes, I do it all manually. I don't have trust in this system to do this automatically, so every 3 months I manually update the certificate using certbot. I only noticed recently that I was still getting certs that use the DST Root CA X3, because Chrome still says the cert of the site is fine.

1 Like
12

Ok, so it seems Kestrel uses an updated file, but we should double-check that with:

openssl pkcs12 -info -nokeys </etc/letsencrypt/live/arcticmanager.com/certificate.pfx

To temper your expectations a little bit: I suspect the PFX is fine, but Kestrel/ASP.NET are doing some kind of #)(#)$&#(% strange #($)#($ f.ck.d up #)($()# weird (#*$(# with the certificate chain and I'm not one able to fix that. But perhaps some ASP.NET guru comes along, who knows.

I see there are a few Github issues related to chains and Kestrel, like this one here: Kestrel on Debian/Ubuntu not sending private intermediate cert · Issue #36202 · dotnet/aspnetcore · GitHub or this one: Support specifying a full certificate chain in HttpsConnectionAdapterOptions · Issue #21513 · dotnet/aspnetcore · GitHub There might be multiple ways to configure Kestrel with the certificate and the chain instead of using the PFX.. So perhaps you require a different configuration method supporting the correct chain stuff.

2 Likes
13 
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
    localKeyID: 98 FF 63 4D 14 EE 50 C4 60 0E 1B 10 7A 47 F5 60 91 0F B2 D0
subject=/CN=arcticmanager.com
issuer=/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----
MIIFKDCCBBCgAwIBAgISA5G0Lla32ZZGoMHqy7/JzgimMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEyMjkxNTAwMDlaFw0yMjAzMjkxNTAwMDhaMBwxGjAYBgNVBAMT
EWFyY3RpY21hbmFnZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwjEwHlrFkmx1mt7j2GBmuUA5cV0XTAOMzdcD6IidnfKZdwpWopkge0cLu8Gt
hgcHjQFktVdBSI6AmiN+wwO6CNGcjfRv4a28VcUc2qoIDvHGIXgBFUMcpzxCfnVa
y5SguPplrKj0QTVhjt6soTXu2xuReYlCrjKcssPRODEMN7yQUPYODV+WV0spFI7/
eVkDrdKf7myy1OjoOzrm6SFz06mIvt0ue3Rk69opeDVqq10nymoW8Y4zZhJFa5uH
86KoAohHkK17tfnnM91u/Hyg6yzZZgtkuyYbOzXsIw+gc8X+3NiMrR/D/tw1OXIs
lvuR38LbpfREP8IpBktahnjrMwIDAQABo4ICTDCCAkgwDgYDVR0PAQH/BAQDAgWg
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0G
A1UdDgQWBBQ+nllJkAPuN3/gOKmcwNxn7hFrIDAfBgNVHSMEGDAWgBQULrMXt1hW
y65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6
Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iu
b3JnLzAcBgNVHREEFTATghFhcmN0aWNtYW5hZ2VyLmNvbTBMBgNVHSAERTBDMAgG
BmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3Bz
LmxldHNlbmNyeXB0Lm9yZzCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB3AEalVet1
+pEgMLWiiWn0830RLEF0vv1JuIWr8vxw/m1HAAABfgbrlxsAAAQDAEgwRgIhAPJX
NNSSXdzv32eTkVIg8+33yQOEneBxniFwtvW3OMnvAiEAqVKYM4nq0/mi9pOHOdA+
QJ/7/aAFqPZnAQpJqpkMbTMAdQDfpV6raIJPH2yt7rhfTj5a6s2iEqRqXo47EsAg
RFwqcwAAAX4G65joAAAEAwBGMEQCIB6NDvlLVQPq9gP4ELvJTDu/niiGr0XvHbKX
m60JrUEAAiA+IePHFze17kkjv3tk7XIJf8ZcRDCY/6XU5pK2BgOuWjANBgkqhkiG
9w0BAQsFAAOCAQEAPC4lBFjxN84hQJOQrS+96C8MELFi/qh+ePZwYqpY3r2osd1c
jB81wfZ94bkP95eWHGatasunybjMSvU2fTA2nSxL4btmNwZIKhtEdQKvHjVtwmFw
XLxv+aGKUEJYcDrB11RkIqOmJU6qaqs9VID4Yi4HLvSqsCF+1ev9Lk4jfeMmXmO9
77zx8wxZ53BqqIHFijQoHQ3Bd/UWY/TDHCLogocZkcBhPhq9Jp/pDAKGGwv0I4N5
IRYNuYR+N0Jc9cQ6TJ0rw37o4kBnDc5DDvPXL3/gT2T5uwKupmjCUPNQRH8z2Ae1
IPrUQJ9ySuq045XLHCboPQ48Sd+9VEofyGdc3w==
-----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

I indeed spot ISRG Root X1 being used, so it seems like your suspicions are correct and Kestrel/ASP.NET is f*ck#ng with me here. I really hoped it wouldn't come down to me needing to change the source code, but got the feeling it will be imminent.

1 Like
14

As I said, I don't have experience with Kestrel/ASP.NET et cetera, but it seems to be so indeed. Kestrel is being fed a correct PFX, but it just ignores the chain in the PFX and does its own thing. I really hate stuff like that. (And thus I'm not touching Windows stuff too..)

3 Likes
15

Sounds like you may need to switch CAs (to any other that is FREE and ACME friendly).

1 Like
16

Which one(s) will common clients be able to build a trust chain for given only the leaf?

1 Like
18

Why only a leaf?
[what did I miss?]

I see fullchain.pem being used:

1 Like
19

Seems you can give Kestrel a chain but it only sends the leaf. See Osiris #12 and #14

I poked some thru the threads he found (and others) and seems hopeless re: the chain.

1 Like
20

The whole point behind the topic :wink:

1 Like
21

So that won't "workaround" this R3 problem?

1 Like