I have configured SSL on a number of subdomains including
https://us.wottot.com
On my PC I can view the resulting web page without any problems so this
leads me to believe the SSL configuration is correct. However, when I try
to access the same page with my Android device I get a Your connection is
not private error. The problem doesn't exist when accessing other secure
websites so this leads me to believe that there is some error in the
configuration which is specific to Android devices. Any general ideas what
I should look for?
James Read
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/5fc7e3ea/attachment.htm>
On Mon, 14 Nov 2022 at 17:31, James Read <jamesread5737 at gmail.com> wrote:
>
> I have configured SSL on a number of subdomains including https://us.wottot.com
>
> On my PC I can view the resulting web page without any problems so this leads me to believe the SSL configuration is correct.
Wrong, the intermediate certificate "Starfield Secure Certificate
Authority - G2" is missing, instead you are sending 2 unnecessary root
certificates "Starfield Root Certificate Authority - G2" and
"Starfield Technologies, Inc. / Starfield Class 2 Certification
Authority".
Remove the 2 root certificates and add the intermediate certificate.
It can work in some cases, based on whatever intermediate certificates
your browser currently has in the cache. That doesn't make it a
correct configuration.
Use tools like the ssllabs ssltest or testssl.sh to check for chain issues:
https://www.ssllabs.com/ssltest/analyze.html?d=us.wottot.com
-lukas
Your CA bundle / SSL Chain is incomplete
Check your SSL vendor and make sure that your Certificate chain is complete
( ssl_certificate_key file )
On Mon, Nov 14, 2022 at 8:02 PM James Read <jamesread5737 at gmail.com> wrote:
> I have configured SSL on a number of subdomains including
> https://us.wottot.com
>
> On my PC I can view the resulting web page without any problems so this
> leads me to believe the SSL configuration is correct. However, when I try
> to access the same page with my Android device I get a Your connection is
> not private error. The problem doesn't exist when accessing other secure
> websites so this leads me to believe that there is some error in the
> configuration which is specific to Android devices. Any general ideas what
> I should look for?
>
> James Read
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/6f776c90/attachment.htm>
On Mon, Nov 14, 2022 at 5:58 PM Lukas Tribus <lukas at ltri.eu> wrote:
> On Mon, 14 Nov 2022 at 17:31, James Read <jamesread5737 at gmail.com> wrote:
> >
> > I have configured SSL on a number of subdomains including
> https://us.wottot.com
> >
> > On my PC I can view the resulting web page without any problems so this
> leads me to believe the SSL configuration is correct.
>
> Wrong, the intermediate certificate "Starfield Secure Certificate
> Authority - G2" is missing,
Thanks for that. Any idea where I can find the intermediate certificate?
> instead you are sending 2 unnecessary root
> certificates "Starfield Root Certificate Authority - G2" and
> "Starfield Technologies, Inc. / Starfield Class 2 Certification
> Authority".
> Remove the 2 root certificates and add the intermediate certificate.
>
> It can work in some cases, based on whatever intermediate certificates
> your browser currently has in the cache. That doesn't make it a
> correct configuration.
>
> Use tools like the ssllabs ssltest or testssl.sh to check for chain issues:
>
> https://www.ssllabs.com/ssltest/analyze.html?d=us.wottot.com
>
>
>
> -lukas
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/0349b068/attachment.htm>
On Mon, 14 Nov 2022 at 21:00, James Read <jamesread5737 at gmail.com> wrote:
>
>
>
> On Mon, Nov 14, 2022 at 5:58 PM Lukas Tribus <lukas at ltri.eu> wrote:
>>
>> On Mon, 14 Nov 2022 at 17:31, James Read <jamesread5737 at gmail.com> wrote:
>> >
>> > I have configured SSL on a number of subdomains including https://us.wottot.com
>> >
>> > On my PC I can view the resulting web page without any problems so this leads me to believe the SSL configuration is correct.
>>
>> Wrong, the intermediate certificate "Starfield Secure Certificate
>> Authority - G2" is missing,
>
>
> Thanks for that. Any idea where I can find the intermediate certificate?
You can find the intermediate certificate download link in the ssllabs
ssltest test results
Issuer: Starfield Secure Certificate Authority - G2
--> AIA: http://certificates.starfieldtech.com/repository/sfig2.crt
Lukas
On Mon, 14 Nov 2022 at 21:09, Lukas Tribus <lukas at ltri.eu> wrote:
>
> On Mon, 14 Nov 2022 at 21:00, James Read <jamesread5737 at gmail.com> wrote:
> >
> >
> >
> > On Mon, Nov 14, 2022 at 5:58 PM Lukas Tribus <lukas at ltri.eu> wrote:
> >>
> >> On Mon, 14 Nov 2022 at 17:31, James Read <jamesread5737 at gmail.com> wrote:
> >> >
> >> > I have configured SSL on a number of subdomains including https://us.wottot.com
> >> >
> >> > On my PC I can view the resulting web page without any problems so this leads me to believe the SSL configuration is correct.
> >>
> >> Wrong, the intermediate certificate "Starfield Secure Certificate
> >> Authority - G2" is missing,
> >
> >
> > Thanks for that. Any idea where I can find the intermediate certificate?
>
> You can find the intermediate certificate download link in the ssllabs
> ssltest test results
>
> Issuer: Starfield Secure Certificate Authority - G2
> --> AIA: http://certificates.starfieldtech.com/repository/sfig2.crt
For nginx you need the base64 encoding, which is:
https://ssl-ccp.secureserver.net/repository/sfig2.crt.pem
Lukas
On Mon, Nov 14, 2022 at 8:20 PM Lukas Tribus <lukas at ltri.eu> wrote:
> On Mon, 14 Nov 2022 at 21:09, Lukas Tribus <lukas at ltri.eu> wrote:
> >
> > On Mon, 14 Nov 2022 at 21:00, James Read <jamesread5737 at gmail.com>
> wrote:
> > >
> > >
> > >
> > > On Mon, Nov 14, 2022 at 5:58 PM Lukas Tribus <lukas at ltri.eu> wrote:
> > >>
> > >> On Mon, 14 Nov 2022 at 17:31, James Read <jamesread5737 at gmail.com>
> wrote:
> > >> >
> > >> > I have configured SSL on a number of subdomains including
> https://us.wottot.com
> > >> >
> > >> > On my PC I can view the resulting web page without any problems so
> this leads me to believe the SSL configuration is correct.
> > >>
> > >> Wrong, the intermediate certificate "Starfield Secure Certificate
> > >> Authority - G2" is missing,
> > >
> > >
> > > Thanks for that. Any idea where I can find the intermediate
> certificate?
> >
> > You can find the intermediate certificate download link in the ssllabs
> > ssltest test results
> >
> > Issuer: Starfield Secure Certificate Authority - G2
> > --> AIA: http://certificates.starfieldtech.com/repository/sfig2.crt
>
> For nginx you need the base64 encoding, which is:
>
> https://ssl-ccp.secureserver.net/repository/sfig2.crt.pem
>
>
I tried adding that certificate but sudo nginx -t now returns the following
error:
nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/private/wottot.com.key")
failed (SSL: error:0B080074:x509 certificate
routines:X509_check_private_key:key values mismatch)
nginx: configuration file /etc/nginx/nginx.conf test failed
James Read
>
> Lukas
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/2f8a1e0f/attachment.htm>
On Mon, 14 Nov 2022 at 21:33, James Read <jamesread5737 at gmail.com> wrote:
>> For nginx you need the base64 encoding, which is:
>>
>> https://ssl-ccp.secureserver.net/repository/sfig2.crt.pem
>>
>
> I tried adding that certificate but sudo nginx -t now returns the following error:
>
> nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/private/wottot.com.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
> nginx: configuration file /etc/nginx/nginx.conf test failed
The intermediate certificate does not replace your own certificate. It
replaces the unrelated root certificates.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
> the primary certificate comes first, then the intermediate certificates
So the file needs to contain first your certificate and then the
intermediate one.
Lukas
On Mon, Nov 14, 2022 at 9:33 PM Lukas Tribus <lukas at ltri.eu> wrote:
> On Mon, 14 Nov 2022 at 21:33, James Read <jamesread5737 at gmail.com> wrote:
> >> For nginx you need the base64 encoding, which is:
> >>
> >> https://ssl-ccp.secureserver.net/repository/sfig2.crt.pem
> >>
> >
> > I tried adding that certificate but sudo nginx -t now returns the
> following error:
> >
> > nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/private/wottot.com.key")
> failed (SSL: error:0B080074:x509 certificate
> routines:X509_check_private_key:key values mismatch)
> > nginx: configuration file /etc/nginx/nginx.conf test failed
>
> The intermediate certificate does not replace your own certificate. It
> replaces the unrelated root certificates.
>
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
>
> > the primary certificate comes first, then the intermediate certificates
>
> So the file needs to contain first your certificate and then the
> intermediate one.
>
OK. Thanks. I rearranged the file and deleted some certificates. Now sslabs
is reporting no chain issues for Certificate #1: RSA 2048 bits
(SHA256withRSA) but for Certificate #2: RSA 2048 bits (SHA256withRSA) it is
reporting
Chain issues
*Incomplete, Extra certs, Contains anchor*
Any ideas?
James Read
>
>
> Lukas
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/87bac186/attachment.htm>
On Mon, Nov 14, 2022 at 4:59 PM James Read <jamesread5737 at gmail.com> wrote:
> ...
> OK. Thanks. I rearranged the file and deleted some certificates. Now
> sslabs is reporting no chain issues for Certificate #1: RSA 2048 bits
> (SHA256withRSA) but for Certificate #2: RSA 2048 bits (SHA256withRSA) it
> is reporting
> Chain issues
> *Incomplete, Extra certs, Contains anchor*
>
> Any ideas?
>
The certificate chain for us.wottot.com still looks off to me. depth=1 and
depth=0 are Ok. But at depth=2, you do not need the certificate with 'CN =
Starfield Root Certificate Authority - G2'.
You don't send the Root CA. User agents must already have the Root CA in
their store (and trust it). Some user agents, like browsers, even carry
around a bunch of intermediate certificates.
Jeff
$ openssl s_client -connect us.wottot.com:443 -servername us.wottot.com
-showcerts
CONNECTED(00000003)
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", CN = Starfield Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield
Secure Certificate Authority - G2
verify return:1
depth=0 CN = *.wottot.com
verify return:1
---
Certificate chain
0 s:CN = *.wottot.com
i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield
Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
MIIGszCCBZugAwIBAgIJALmBI4vKMs8xMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYD
VQQGEwJVUzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEl
MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEzMDEGA1UECxMq
aHR0cDovL2NlcnRzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkvMTQwMgYD
VQQDEytTdGFyZmllbGQgU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eSAtIEcy
MB4XDTIyMTExMjE4MjQzNVoXDTIzMTExMjE4MjQzNVowFzEVMBMGA1UEAwwMKi53
b3R0b3QuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4tT+zLfe
hBL/Y/fylqijUY1cusctX/bw7n4pcyS3ZyGcl+zEq4C/uNlgXh5uUBbfO0Zd+75R
rdYLjBjO99RsJU5x1EBiPNlvvBIILXmSDiEhsWdUgu9Irsu/VI85KMq8rIWTiRuD
y4r387oU/F2L9tYS9Lg1YOHzDidTKruZzKp9CSyxAjV/RKfEkXHKZHnPd7sjDtDq
BuagoxBNMfkYX6zwGz/iARlu4bIsFIrmvdGVyZUYJ7RM2FL9F5LfMZHGagnP96UU
OwT7yoDw6gkgSHsfA2+6D36WcUJOgIcJ96259KstI94UupqE3S+msRRWhZhUR8hh
dje5PYUuhQjkBwIDAQABo4IDUDCCA0wwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMD0GA1UdHwQ2MDQw
MqAwoC6GLGh0dHA6Ly9jcmwuc3RhcmZpZWxkdGVjaC5jb20vc2ZpZzJzMS01MDUu
Y3JsMGMGA1UdIARcMFowTgYLYIZIAYb9bgEHFwEwPzA9BggrBgEFBQcCARYxaHR0
cDovL2NlcnRpZmljYXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBvc2l0b3J5LzAI
BgZngQwBAgEwgYIGCCsGAQUFBwEBBHYwdDAqBggrBgEFBQcwAYYeaHR0cDovL29j
c3Auc3RhcmZpZWxkdGVjaC5jb20vMEYGCCsGAQUFBzAChjpodHRwOi8vY2VydGlm
aWNhdGVzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkvc2ZpZzIuY3J0MB8G
A1UdIwQYMBaAFCVFgWhQJjg9Oy0svs1q2bY9s2ZjMCMGA1UdEQQcMBqCDCoud290
dG90LmNvbYIKd290dG90LmNvbTAdBgNVHQ4EFgQUtFbGpGeJWh/YFrN8gpFP2i1o
SuMwggF9BgorBgEEAdZ5AgQCBIIBbQSCAWkBZwB1AOg+0No+9QY1MudXKLyJa8kD
08vREWvs62nhd31tBr1uAAABhG0WHCEAAAQDAEYwRAIgL/MHOaozMCv2hKYtk/ga
PCf1ybV5mQ4B0DS0SrUPuQICIGdGnBh2tP76LFzcaw+JIHXOe3gPCyS4UBSG4tHC
T7WaAHYAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61IAAAGEbRYdBAAA
BAMARzBFAiAb2UR4BmIPuVbcB+KmdQDM6FcaVkjyytTCrMccdnQaLgIhAJkB7llf
Gc0UCKeAD54O2ZATfInOOQLyIqN2K7UC3puqAHYAs3N3B+GEUPhjhtYFqdwRCUp5
LbFnDAuH3PADDnk2pZoAAAGEbRYeBQAABAMARzBFAiBSXXglDGJYWi8ia9JZOfxK
gZC7JcYV5p/g9tMsqoqR5QIhANtqc01iTbcJT2m6mtAL1qqQNmKl81PkCvaIEmYp
FmXuMA0GCSqGSIb3DQEBCwUAA4IBAQCkpiRc26hkqadkYCHRqwadjI4PIzyQfgyh
3tGoGfAPx2fwNuVPHq7tStALxb920EwRk3oHn47zm7iq/VWYF/Wo70RGgm7S75Gq
vFOGqgrbDSc/gVdDXlT5r9yeJANg+cmuffoZIDcAiFELz0crp9WlWiw0s2P5LKGn
wZIwjWF049hdvuXgiMUlsR294dgZHduFyfaXtVjxRgxcaiZV5ckHhyfHnpb7WyVL
jcqMt2TQa/fzYxpmk7ttuNfa0PMjj77rEpRM6hmgtVcq/Nde4D2RywOufiHKF//c
lpRCdIuPJmsMHOVkLmo8bNxgd5RzK4+tKmugYaQtOwSXXHaPFC2i
-----END CERTIFICATE-----
1 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield
Secure Certificate Authority - G2
i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", CN = Starfield Root Certificate Authority - G2
-----BEGIN CERTIFICATE-----
MIIFADCCA+igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBjzELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT
HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xMjAwBgNVBAMTKVN0YXJmaWVs
ZCBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAw
MFoXDTMxMDUwMzA3MDAwMFowgcYxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6
b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMSUwIwYDVQQKExxTdGFyZmllbGQgVGVj
aG5vbG9naWVzLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydHMuc3RhcmZpZWxk
dGVjaC5jb20vcmVwb3NpdG9yeS8xNDAyBgNVBAMTK1N0YXJmaWVsZCBTZWN1cmUg
Q2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDlkGZL7PlGcakgg77pbL9KyUhpgXVObST2yxcT+LBxWYR6ayuF
pDS1FuXLzOlBcCykLtb6Mn3hqN6UEKwxwcDYav9ZJ6t21vwLdGu4p64/xFT0tDFE
3ZNWjKRMXpuJyySDm+JXfbfYEh/JhW300YDxUJuHrtQLEAX7J7oobRfpDtZNuTlV
Bv8KJAV+L8YdcmzUiymMV33a2etmGtNPp99/UsQwxaXJDgLFU793OGgGJMNmyDd+
MB5FcSM1/5DYKp2N57CSTTx/KgqT3M0WRmX3YISLdkuRJ3MUkuDq7o8W6o0OPnYX
v32JgIBEQ+ct4EMJddo26K3biTr1XRKOIwSDAgMBAAGjggEsMIIBKDAPBgNVHRMB
Af8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUJUWBaFAmOD07LSy+
zWrZtj2zZmMwHwYDVR0jBBgwFoAUfAwyH6fZMH/EfWijYqihzqsHWycwOgYIKwYB
BQUHAQEELjAsMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC5zdGFyZmllbGR0ZWNo
LmNvbS8wOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5zdGFyZmllbGR0ZWNo
LmNvbS9zZnJvb3QtZzIuY3JsMEwGA1UdIARFMEMwQQYEVR0gADA5MDcGCCsGAQUF
BwIBFitodHRwczovL2NlcnRzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkv
MA0GCSqGSIb3DQEBCwUAA4IBAQBWZcr+8z8KqJOLGMfeQ2kTNCC+Tl94qGuc22pN
QdvBE+zcMQAiXvcAngzgNGU0+bE6TkjIEoGIXFs+CFN69xpk37hQYcxTUUApS8L0
rjpf5MqtJsxOYUPl/VemN3DOQyuwlMOS6eFfqhBJt2nk4NAfZKQrzR9voPiEJBjO
eT2pkb9UGBOJmVQRDVXFJgt5T1ocbvlj2xSApAer+rKluYjdkf5lO6Sjeb6JTeHQ
sPTIFwwKlhR8Cbds4cLYVdQYoKpBaXAko7nv6VrcPuuUSvC33l8Odvr7+2kDRUBQ
7nIMpBKGgc0T0U7EPMpODdIm8QC3tKai4W56gf0wrHofx1l7
-----END CERTIFICATE-----
---
Server certificate
subject=CN = *.wottot.com
issuer=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies,
Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield
Secure Certificate Authority - G2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/598d71f1/attachment.htm>
On Mon, 14 Nov 2022 at 22:56, James Read <jamesread5737 at gmail.com> wrote:
>> So the file needs to contain first your certificate and then the
>> intermediate one.
>
>
> OK. Thanks. I rearranged the file and deleted some certificates. Now sslabs is reporting no chain issues for Certificate #1: RSA 2048 bits (SHA256withRSA)
Correct, a TLS session negotiated with SNI us.wottot.com is now
correctly showing the intermediate certificate.
You are not sending the root certificate here, which is also
completely correct at this point.
The previous poster is confused by the openssl output, which actually
shows a correctly configured server (for the particular SNI value
us.wottot.com).
So all browsers and mobile devices should be able to connect to
us.wottot.com now.
> but for Certificate #2: RSA 2048 bits (SHA256withRSA) it is reporting
> Chain issues Incomplete, Extra certs, Contains anchor
This is a fallback for clients not matching us.wottot.com.
You probably have a "default" ssl server in your configuration that is
still pointing to a path that you did not cleanup. You should only
define this certificate once in your nginx configurations, not
multiple times in different server blocks.
Lukas
On Mon, Nov 14, 2022 at 10:34 PM Lukas Tribus <lukas at ltri.eu> wrote:
> On Mon, 14 Nov 2022 at 22:56, James Read <jamesread5737 at gmail.com> wrote:
> >> So the file needs to contain first your certificate and then the
> >> intermediate one.
> >
> >
> > OK. Thanks. I rearranged the file and deleted some certificates. Now
> sslabs is reporting no chain issues for Certificate #1: RSA 2048 bits
> (SHA256withRSA)
>
> Correct, a TLS session negotiated with SNI us.wottot.com is now
> correctly showing the intermediate certificate.
> You are not sending the root certificate here, which is also
> completely correct at this point.
>
> The previous poster is confused by the openssl output, which actually
> shows a correctly configured server (for the particular SNI value
> us.wottot.com).
>
> So all browsers and mobile devices should be able to connect to
> us.wottot.com now.
>
>
> > but for Certificate #2: RSA 2048 bits (SHA256withRSA) it is reporting
> > Chain issues Incomplete, Extra certs, Contains anchor
>
> This is a fallback for clients not matching us.wottot.com.
>
> You probably have a "default" ssl server in your configuration that is
> still pointing to a path that you did not cleanup. You should only
> define this certificate once in your nginx configurations, not
> multiple times in different server blocks.
>
>
>
Thanks for clarifying things. I have a single default file. Here are the
contents:
cat /etc/nginx/sites-available/default
##
# You should look at the following URL's in order to grasp a solid
understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
#
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/
and
# leave it as reference inside of sites-available where it will continue to
be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink
that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
Is there a problem with configuration?
James Read
> Lukas
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/e69b297f/attachment.htm>
On Mon, Nov 14, 2022 at 10:34 PM Lukas Tribus <lukas at ltri.eu> wrote:
> On Mon, 14 Nov 2022 at 22:56, James Read <jamesread5737 at gmail.com> wrote:
> >> So the file needs to contain first your certificate and then the
> >> intermediate one.
> >
> >
> > OK. Thanks. I rearranged the file and deleted some certificates. Now
> sslabs is reporting no chain issues for Certificate #1: RSA 2048 bits
> (SHA256withRSA)
>
> Correct, a TLS session negotiated with SNI us.wottot.com is now
> correctly showing the intermediate certificate.
> You are not sending the root certificate here, which is also
> completely correct at this point.
>
> The previous poster is confused by the openssl output, which actually
> shows a correctly configured server (for the particular SNI value
> us.wottot.com).
>
> So all browsers and mobile devices should be able to connect to
> us.wottot.com now.
>
>
> > but for Certificate #2: RSA 2048 bits (SHA256withRSA) it is reporting
> > Chain issues Incomplete, Extra certs, Contains anchor
>
> This is a fallback for clients not matching us.wottot.com.
>
> You probably have a "default" ssl server in your configuration that is
> still pointing to a path that you did not cleanup. You should only
> define this certificate once in your nginx configurations, not
> multiple times in different server blocks.
>
>
>
OK. Problem solved. Thanks for your patience and your explanations.
James Read
>
> Lukas
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221114/303104c0/attachment.htm>