Provide ssl.pem file with Let's Encrypt

Let's Encrypt implementation on Virtualmin already provides ssl.ca, ssl.cert and ssl.key files in websites' home directories. However, sometimes applications require .pem file and we go around this problem by simply concatenating ssl files, which works perfectly fine. But I thought to eliminate additional manual work or scripting Virtulamin could actually take such a simple task.

Thanks for consideration!

Status: 
Active

Comments

This one has been ignored since September 2nd, 2017 :(

Jamie, if you don't like the idea of automatically generating .pem file at the same time when ssl.cert and ssl.key files are generated/renewed, then could you please at least tell us how to check if SSL certificate is generated or renewed in the post-installation script, so we could automatize generation of ssl.pem file?

Ideally, this should be done Virtualmin just by triggering the following command after SSL files are generated/renewed:

cat $path/ssl.cert $path/ssl.key $path/ssl.ca > $path/ssl.pem

Actually, after looking into this some more, I will add a combined cert file - it's useful for Dovecot and Nginx. Look for it in the next release.

The next release (6.01) will create an ssl.combined file that contains the domain and CA certs concatenated.

Status: Active » Fixed
The next release (6.01) will create an ssl.combined file that contains the domain and CA certs concatenated.

Excellent and thank you very much!

Status:
Fixed
»
Active

Have to re-open this as our proxy is failing with the ssl.combined generated by Virtualmin, because it is missing one of the keys:

cat ssl.combined
-----BEGIN CERTIFICATE-----
MIIFHDCCBASgAwIBAgISA/pMfK5IhmHUxYyOGM/KusfwMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzEwMDQyMzA2MjJaFw0x
ODAxMDIyMzA2MjJaMBwxGjAYBgNVBAMTEXN1YjkuY3J5cHR1c2EuY29tMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8Xfk6evpkQVOmhiQkqCFBo2BG8XO
GBGz8TTziJJbbNMc/KmyhDlr+tuYSOhk6RrO3zc2tkvU6oVVNniYYqX2hRENo023
TgRgTwsGWS4RRSpnt15Op69iRNn4bgJDjQiMbq1uuW+7ys68PfyApqwvK8w3pzBs
ojaw5wRrRFj2DSKeVcbyJX7IknHLFH2m5a4Zdc1tWLqfu9w7Qla6Wp2dXcDn/9mF
Bj+qnzeUEhS+XsFho6uP58/jhRN4nCwknPSBQkclphqVcMI/lm1qp9qj3VORy7wT
Dc8oYxREqnDV1k3qoTf4d2Mt6le4jV+03GMfopSa3KJrSdjliugIxEJOIwIDAQAB
o4ICKDCCAiQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR/a8M2he6TrOopJOt3jWX3
/9RdVzAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcB
AQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlw
dC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlw
dC5vcmcvMDMGA1UdEQQsMCqCEXN1YjkuY3J5cHR1c2EuY29tghV3d3cuc3ViOS5j
cnlwdHVzYS5jb20wgf4GA1UdIASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8T
AQEBMIHWMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCB
qwYIKwYBBQUHAgIwgZ4MgZtUaGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJl
bGllZCB1cG9uIGJ5IFJlbHlpbmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRh
bmNlIHdpdGggdGhlIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczov
L2xldHNlbmNyeXB0Lm9yZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
TvlEsxJCV1GInmwGPbh9VJomHR3uLp6ncDlgqZEpCyRbHopNiHhrf2zJ4zLVXTA/
A+vpPVezftkMxfnSCm9FTPnaqy/NTkCnCGNpQY5F75HEfKhTCejQQNo2xdfECndY
vCUPgCfiluibI3cDj/4uVttQz3uw9HFUu4WR49lZD9MU1T3Tsox+DHM6/8xg0fUr
iZHB+q+kdKiRK8jp63VoEEtuqG7M8oj1nvhq8uF0HWLXVA1wA5JyblEgX1bpCqgJ
TQpfpQYYel/Ev8WPnFskNCsp3Fk4BSTO/PJm2P3i6C2bCdFGsFw4NqJeFsGrtL2G
4uTGgMXwzDitmXwNhxFHxw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

and its weight in our case is only 3481 MB:

-rwx------ 1 username username 3481 Oct  5 00:07 ssl.combined

However, if we point our proxy to ssl.pem, generated by running the cat ssl.cert ssl.key ssl.ca > ssl.pem command, then everything works fine. To compare, its content:

cat ssl.pem
-----BEGIN CERTIFICATE-----
MIIFHDCCBASgAwIBAgISA/pMfK5IhmHUxYyOGM/KusfwMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzEwMDQyMzA2MjJaFw0x
ODAxMDIyMzA2MjJaMBwxGjAYBgNVBAMTEXN1YjkuY3J5cHR1c2EuY29tMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8Xfk6evpkQVOmhiQkqCFBo2BG8XO
GBGz8TTziJJbbNMc/KmyhDlr+tuYSOhk6RrO3zc2tkvU6oVVNniYYqX2hRENo023
TgRgTwsGWS4RRSpnt15Op69iRNn4bgJDjQiMbq1uuW+7ys68PfyApqwvK8w3pzBs
ojaw5wRrRFj2DSKeVcbyJX7IknHLFH2m5a4Zdc1tWLqfu9w7Qla6Wp2dXcDn/9mF
Bj+qnzeUEhS+XsFho6uP58/jhRN4nCwknPSBQkclphqVcMI/lm1qp9qj3VORy7wT
Dc8oYxREqnDV1k3qoTf4d2Mt6le4jV+03GMfopSa3KJrSdjliugIxEJOIwIDAQAB
o4ICKDCCAiQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR/a8M2he6TrOopJOt3jWX3
/9RdVzAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcB
AQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlw
dC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlw
dC5vcmcvMDMGA1UdEQQsMCqCEXN1YjkuY3J5cHR1c2EuY29tghV3d3cuc3ViOS5j
cnlwdHVzYS5jb20wgf4GA1UdIASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8T
AQEBMIHWMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCB
qwYIKwYBBQUHAgIwgZ4MgZtUaGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJl
bGllZCB1cG9uIGJ5IFJlbHlpbmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRh
bmNlIHdpdGggdGhlIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczov
L2xldHNlbmNyeXB0Lm9yZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
TvlEsxJCV1GInmwGPbh9VJomHR3uLp6ncDlgqZEpCyRbHopNiHhrf2zJ4zLVXTA/
A+vpPVezftkMxfnSCm9FTPnaqy/NTkCnCGNpQY5F75HEfKhTCejQQNo2xdfECndY
vCUPgCfiluibI3cDj/4uVttQz3uw9HFUu4WR49lZD9MU1T3Tsox+DHM6/8xg0fUr
iZHB+q+kdKiRK8jp63VoEEtuqG7M8oj1nvhq8uF0HWLXVA1wA5JyblEgX1bpCqgJ
TQpfpQYYel/Ev8WPnFskNCsp3Fk4BSTO/PJm2P3i6C2bCdFGsFw4NqJeFsGrtL2G
4uTGgMXwzDitmXwNhxFHxw==
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA8Xfk6evpkQVOmhiQkqCFBo2BG8XOGBGz8TTziJJbbNMc/Kmy
hDlr+tuYSOhk6RrO3zc2tkvU6oVVNniYYqX2hRENo023TgRgTwsGWS4RRSpnt15O
p69iRNn4bgJDjQiMbq1uuW+7ys68PfyApqwvK8w3pzBsojaw5wRrRFj2DSKeVcby
JX7IknHLFH2m5a4Zdc1tWLqfu9w7Qla6Wp2dXcDn/9mFBj+qnzeUEhS+XsFho6uP
58/jhRN4nCwknPSBQkclphqVcMI/lm1qp9qj3VORy7wTDc8oYxREqnDV1k3qoTf4
d2Mt6le4jV+03GMfopSa3KJrSdjliugIxEJOIwIDAQABAoIBAHzFPvvAcwgEfgES
AGJDn3krVTNMmpnFS/2vJsfDGIq665eC+ENqiGkvXxkNPFdXCt48YYEA3hvwmX90
AQm4SBGqJinj1nvxtvIg+D7Mlw/uQXl2uZ3b+iMpnjz53n3ZlPb7luMq4RaCjLJa
7v8wqY8wDvHNC9Ul/XLhzaubbEiMQeJx3nIvxwXFyNtEA7c71+t81cKMP6kmi6Wz
NRRajaKCIMX+XBNKZL1nl4TyzETeXLnY05nSYGOoFXAyrLacCThJ+KNgmeVzzXR0
BRh/0GYGCMTDefXqAgGYaq9stV8MSbcKH5UlCXkGxJyDnJKlKU6+gLz0Sd4XvB4G
cfb4isECgYEA+YEJ4L7yJVSVd3iuwWnNTtYFHxndTKahVrW3FjU5gNVEI39zA5Jx
7Ca8c4iVp0Iluhxp2GpqCnPKN7X3pE547IBvGL2hDz0NoZheKMSdYqX5N2whqOhd
93Jnn5NNalyO/SQW8BbyV7MXm7Jevjd6bCaH26e9krXIzYgIJYIHrUUCgYEA98FM
B4MbqDgjszcTqqztrfaIAkp2A0XOirVk1hqCCFshmoeLFChW93ER64ZViIJPj+FT
ZTiHk9YD0UGV1RX9yi+093VwDMdJjO+YKoJgzv264j6ca4bXRvyw6AozaPe1EGth
VJViRbCgWYy+nJtXKb+asNjuOpgK0Mk4bSqQQEcCgYEAl5Mi8xxNcwxNuUThtbKW
/ZvbhKdr39MjFNBUJ/OxuWjWelJFBxiCiRqHRhDmCbSPwt7cFpOfVDY/1VSA25qo
r9TeqUMag21tyIwON+oqSvHV0yunzztLSrZ/6VvNnh4Y6ARywuzN0SWF5BqaoCiI
AQfvZSwkaOpy0RohCNhT3ZkCgYEAgAACysLG0DMo5pdm9r/fEAiVnjFgJTK0kd9D
mIYbdju28cJjbWel/rMRIhDGMf+5IUm1r070ZMGmOT9cLLnu472gDlVDLabsbf7/
K78uSuK14dudLsR8hnVY5JkYlHudtTz1DSEco4qsXXekpv5umugeAI4jDmys8c9z
8pqR6lMCgYEA8hDJT0NrQE581Ru957s/38fxZjumHu9iNlI4R4CcMA6yJ1FtcQ9M
h+2KcMR6Pgt5piuv0ilzUqLPl6xKccr9MZV7XiuZqN6mwtdeXP9bNGYs/OJ5lPmo
UjhHrHHp79RFGGYZ1IEyhknQpObJ7vFOoLhM9lIUzTfZw5lc36cIkoY=
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

and its weight:

-rwx------ 1 username username 5160 Oct  5 00:12 ssl.pem

Please include all ssl.cert, ssl.key and ssl.ca in ssl.combined.

Also please note that ssl.combined in current implementations always gives Grade B when checking on https://www.ssllabs.com/ssltest because of incomplete chain. And only when you run cat ssl.cert ssl.key ssl.ca > ssl.bundle it is evaluated with A-grade certificate.

Also, here is the quote from https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-i... for your information:

.pem Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. Confusingly, it may also encode a CSR (e.g. as used here) as the PKCS10 format can be translated into PEM. The name is from Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.

So give it a suffix .pem, .bundle or .combined, it is all the same and it gets A-grade evaluation only if includes an entire certificate chain including public key, private key, and root certificates.

Wait, the key has to be in the cert file as well?! That doesn't seem right - they key is usually stored separately, and never sent to SSL clients.

Wait, the key has to be in the cert file as well?! That doesn't seem right - they key is usually stored separately, and never sent to SSL clients.

I am not asserting anything, but please try both ways and test on https://www.ssllabs.com/ssltest to see only bundle file that contain both pass to Grade A evaluation.

Also, please see various specifications and discussions:

  1. From http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL#Configuration:

ssl.pemfile path to the PEM file for SSL support (Should contain both the private key and the certificate)

  1. Apparently there are different ways of creating bundled certificate files and here are the instructions on https://www.digicert.com/ssl-support/pem-ssl-creation.htm to create one of them called:
Creating a .pem with the Private Key and Entire Trust Chain

Log into your DigiCert Management Console and download your Intermediate (DigiCertCA.crt) and Primary Certificates (your_domain_name.crt).
Open a text editor (such as wordpad) and paste the entire body of each certificate into one text file in the following order:

The Private Key - your_domain_name.key
The Primary Certificate - your_domain_name.crt
The Intermediate Certificate - DigiCertCA.crt
The Root Certificate - TrustedRoot.crt
Make sure to include the beginning and end tags on each certificate. The result should look like this:

-----BEGIN RSA PRIVATE KEY-----
(Your Private Key: your_domain_name.key)
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: your_domain_name.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: DigiCertCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----

Save the combined file as your_domain_name.pem. The .pem file is now ready to use.
  1. Quote from https://www.novell.com/support/kb/doc.php?id=7013103:
A .pem file is a container format that may just include the public certificate or the entire certificate chain (private key, public key, root certificates):
Private Key
Server Certificate (crt, puplic key)
(optional) Intermediate CA and/or bundles if signed by a 3rd party
  1. Another quote from https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-ce...
Combination

In some cases it is advantageous to combine multiple pieces of the X.509 infrastructure into a single file.  One common example would be to combine both the private key and public key into the same certificate.
  1. Another quote from https://helpdesk.ssls.com/hc/en-us/articles/204093372-What-are-certifica...
You may also encounter *.pfx files. This is an archive file format for storing several cryptographic objects in a single file. In the scope of SSL certificates for SSL/TLS client and SSL/TLS webserver authentication (the ones we offer), a .pfx file must contain the end-entity certificate (issued to your domain), a matching private key, and may optionally include an intermediate certification authority (a.k.a. CA Bundle).
  1. https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-i...
.pem Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates.

So apparently there is no such a rule that bundled certificate files must not contain private keys. Some proxy servers like LightHTTP, ngnix, pound require single bundle file. I am not sure why private key is included, but it could be that private key is never transmitted over the net, but is required locally to match public key for browsers to grade the SSL certificate with an A grade.

Right, I've certainly seen cases where both the public and private keys were in the same file. But what confuses me is why the presence of the private key would be needed to pass any kind of SSL validation test when (by definition!) the private key isn't included in any response sent by the webserver.

I really don't know, Jamie, but run tests - it never gets A-grade if the bundled file doesn't contain private key.

Take a look here Chain .. Fullchain ... ? https://letsencrypt.readthedocs.io/en/stable/using.html#where-are-my-cer...

Jfro, thanks for the update. Yes, even on the last link provided it says:

fullchain.pem All certificates, including server certificate. This is concatenation of chain.pem and cert.pem. This is what Apache >= 2.4.8 needs for SSLCertificateFile, and what nginx needs for ssl_certificate.

Those docs don't mention including the private key in fullchain.pem though.

yngens - are you seeing this when using Apache or Nginx? I need to do some tests with our own servers to see if this can be re-produced.

It's Pound, whose settings are similar to Nginx in that respect that both proxy servers require a single bundled SSL file.

And please do not disregard my repetitive requests to run tests - even if you use just Apache https://www.ssllabs.com/ssltest won't give you A-grade without full chain.

Moreover, those instructions all mention about private key.

Perhaps the right answer is to create another separate file that contains the key, cert and chain for use by Pound. I'll do this in the next release, and call it ssl.everything

Status:
Active
»
Closed (fixed)

Since we see ssl.everything and started to successfully use it getting grade A lets mark this issue as fixed and closed.

Thanks Jamie!

Status:
Closed (fixed)
»
Active

Jamie and crew - can this solution please be included in the Webmin LE process, too? It seems that this solution was overlooked for plain old Webmin certs. At the moment, Webmin LE only generates letsencrypt-{ca,cert,key}. It really needs the combined & everything treatment, too, please.

Should be possible, although Webmin itself doesn't require a combined cert file - so what would you use it for?

Browsers like Konqueror don't like the default cert only cert. They don't seem to receive the intermediate certificate. If you administer Webmin, or access Usermin with the Webmin cert, things are unhappy. I concatenated the ca and cert files myself and the errors clear. Like the request above, manually concatenating isn't really a long term solution.

Here's one of my Webmin sites that gets complaints by both users and the ssl checker: https://www.sslshopper.com/ssl-checker.html?hostname=nein.riot.net.au

For that domain, do you have an extracas= line in the /etc/webmin/miniserv.conf file?

Hi all I think I have a solution to the problem @JamieCameron - I had a look at the dovecot.conf file. In there it seems that virtualmin is placing entries under the “!include_try local.conf” section. These entries point to /home/username/ssl.cert, whereas they should be pointing at /home/username/ssl.combined

Please could you change this in the code. If this is sorted out - there shouldn't be any issues with the certs anymore

---To add - this was causing issues with dovecot being properly configured for ssl

This is a known bug in Virtualmin 6.06 - it will be fixed in the next release.