OPNsense Forum

Hello,

since the update I can no longer access the web interface cause of SSL_ERROR_INTERNAL_ERROR_ALERT (Firefox), Chrome says ERR_SSL_PROTOCOL_ERROR.
The Webinterface uses a lets encrypt cert.
I have still access through SSH.

Is there a quick solution for this problem, maybe disable https, but without reset all my network interfaces? or renew cert...?

Thanks

https://twitter.com/opnsense/status/1339847119977533442

If you use Lets Encrypt, log into SSH and use this command:

# php /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php --mode issue --all --force

Thanks,

The twitter comment got me working again:
opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart
Much appreciated.

Regards

did the last update change something on the firewall behaivor?
i noticed our UDP packets (VOIP) are disconnecting after 20 sec. also the web gui is not availble.

I've had to revert lighttpd after updating to 20.7.7_1 and even worse I had tried a reboot when the error first happened. I lost Internet access because Unbound was also down and I had no DNS and only access via SSH. Had to hack a working DNS into resolv.conf before the revert would download and then a full reboot to get everything stable again.


Are their any plans for some kind of on-board rollback to an update so when faced with even worse, no Internet, then we can get back working? I don't have the luxury of stand-by devices or the ability to run VM versions with snapshots. Had my Internet been inaccessible I would have be royally screwed as my mobile access is next to nothing here, and mostly sub-3G which did fortunately work on this occasion to find this thread - without Internet trying to find help is a nightmare.

Quote from: Taomyn on December 21, 2020, 08:27:29 PM


Are their any plans for some kind of on-board rollback to an update so when faced with even worse, no Internet, then we can get back working? I don't have the luxury of stand-by devices or the ability to run VM versions with snapshots. Had my Internet been inaccessible I would have be royally screwed as my mobile access is next to nothing here, and mostly sub-3G which did fortunately work on this occasion to find this thread - without Internet trying to find help is a nightmare.

Then you maybe should wait a week or so with the update and watch the forums for threads ..
For rollback DNS is required, you should be able to to set DNS server in System : Settings : General and tick the checkbox to not use local unbound. Then it should work too.

Quote from: mimugmail on December 22, 2020, 02:46:54 PM
For rollback DNS is required, you should be able to to set DNS server in System : Settings : General and tick the checkbox to not use local unbound. Then it should work too.

Not when the web interface is broken.

Then just wait a week or so

Quote from: mimugmail on December 22, 2020, 05:53:51 PM
Then just wait a week or so

I did that once before - ended up having to reinstall the whole firewall then restore settings from my offsite backup, and not easy to do when the only image you have on-site is a few releases back - you'll never hit everyone's problems no matter how long you delay it. Hardly friendly when it's your only means of Internet connectivity. Some kind of built-in full rollback should be a feature.

Quote from: mimugmail on December 18, 2020, 09:36:41 AM
https://twitter.com/opnsense/status/1339847119977533442

Another confirmed fix, twitter comment got me working again also.

opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart

Does the 20.7.7_1 update fix this and what's the recommended way to update after having reverted just lighttpd?

We don't have a confirm on ERR_SSL_PROTOCOL_ERROR yet.

You can try using

# opnsense-revert -r 20.7.7 lighttpd && configctl webgui restart

and revert back if necessary. Make sure to probe the lighttpd version depending on the mirror used it may not have yet synced to 1.4.58.


Cheers,
Franco

this the fix

opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart

the
opnsense-revert -r 20.7.7 lighttpd && configctl webgui restart is not working

first run the first command of 20.7.6 and access the gun and run the update from the gui to lighted 1.4.58 the errors appears again.

Then it looks like lighttpd is not going to fix that issue. I can't imagine that this is an issue that can't be fixed from the system (switching cert maybe?). Because it is working for a representative amount of users...


Cheers,
Franco

As per lighttpd author: are you using TLS 1.0 or 1.1 to connect to the firewall? TLS 1.2 is the minimum for them by default now.


Cheers,
Franco

Quote from: franco on January 05, 2021, 10:07:16 AM
Then it looks like lighttpd is not going to fix that issue. I can't imagine that this is an issue that can't be fixed from the system (switching cert maybe?). Because it is working for a representative amount of users...


Cheers,
Franco

for me is working too in some boxes, but most of them are crashed

I think the problem is that when you use Lets Encrypt Certificates via acme.sh the certificate in
ssl.pemfile = "/var/etc/cert.pem" (/var/etc/lighty-webConfigurator.conf)
is only the private key + certificate.
The intermediate certifcate is missing. If you put the intermediate certificate into /var/etc/cert.pem and restart the lighthttp it is working for me.
e.g.
cd /var/etc/acme-client/home/<MYNAME>
cat fullchain.cer <MYNAME>.key > /var/etc/cert.pem
Restart lighthttpd

Perhaps it is this simple?

The chain is properly appended, but only if the parent CA(s) are known to System: Trust: Authorities.


Cheers,
Franco

Anyone using macOS, Big Sur in particular?

I'm seeing the issue on all browsers using TLS 1.3 while TLS 1.2 is fine. Wedging lighttpd a bit unbreaks this and the error is gone from all browsers, even after a reboot with all the lighttpd defaults.  :o


Cheers,
Franco

Quote from: franco on January 12, 2021, 12:38:51 PM
The chain is properly appended, but only if the parent CA(s) are known to System: Trust: Authorities.

Hmmm...Let's Encrypt Authority X3 (Let's Encrypt) and R3 (Let's Encrypt) were/are in the trusted Authorities. But the full chain is not copied to the *pem file by the opnsense framework (only key+cert).

Perhaps we are looking at different problems with the same effect!?

If I take a self-signed cert for the webgui => no problem with firefox/chrome/edge (on Windows).
If I take the Lets Encrypt cert => ERR_SSL_PROTOCOL_ERROR in chrome+edge, SSL_ERROR_INTERNAL_ERROR_ALERT in firefox
If I add the intermediate directly in the *pem => No problems

tested TLS1.3, no problem with the fullchain

...
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=XXXXXXXXX
*  start date: Dec  7 22:01:20 2020 GMT
*  expire date: Mar  7 22:01:20 2021 GMT
...

Isn't this what

ssl.ca-file = "/var/etc/ca.pem"

tries to configure?


Cheers,
Franco

Ah... I was wrong... there is no intermediate ca from LetsEncrypt. But the opnsense  chooses the (wrong)

Common Name: Let's Encrypt Authority X3

as CA for the webgui but the CA is now

Common Name: R3

which is a new CA (Valid From: October 7, 2020)

If I put the right CA inside /var/etc/ca.pem it works, too.... I not sure why and how the opnsense chooses the CA which is put in /var/etc/ca.pem.

So, after deleting the old Lets Encrypt CA from the trust store and reissue a new certificate (force via lets encrypt plugin),  everything works automatically. For me it is ok now, perhaps this helps somebody out there. Thanks for your support!

Right, that was part of the 20.7.6 changes that fixed the LE plugin, see

https://github.com/opnsense/changelog/blob/ccba9df41730889889bb7c596db7ca1a4e689eb8/doc/20.7/20.7.6#L9-L11


Cheers,
Franco

Quote from: franco on January 05, 2021, 10:07:16 AM
Then it looks like lighttpd is not going to fix that issue. I can't imagine that this is an issue that can't be fixed from the system (switching cert maybe?). Because it is working for a representative amount of users...


Cheers,
Franco

I just updated both my backup and master, the master runs Let's Encrypt and I had to run: opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart

This got the GUI working again but on updating lighttpd the error came back.

Is it a case of wait for further update or is there something I can do?

Thanks,

Nick

EDIT: Proper schoolboy error and completely missed the 2nd page ignore me please

Quote from: bignick8t3 on January 13, 2021, 06:24:26 PM

Quote from: franco on January 05, 2021, 10:07:16 AM
Then it looks like lighttpd is not going to fix that issue. I can't imagine that this is an issue that can't be fixed from the system (switching cert maybe?). Because it is working for a representative amount of users...


Cheers,
Franco

I just updated both my backup and master, the master runs Let's Encrypt and I had to run:

Code Select Expand

opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart

This got the GUI working again but on updating lighttpd the error came back.

Is it a case of wait for further update or is there something I can do?

Thanks,

Nick

EDIT: Proper schoolboy error and completely missed the 2nd page ignore me please

I am just curious how to do so if you cannot access the gui

Please note that Let's Encrypt users need to reissue their certificates
manually after upgrading to this version to fix the embedded certificate chain
issue with the current signing CA switch going on.

I had to run from the console or ssh if enabled:
opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart

That got me into the GUI where I then forced an update of my LE certificates.

I then ran an update in the usual manner to bring lighttpd back up to date.

Hope this helps

I had this happen to me again upgrading from 20.7.7 with the older 20.7.6 lighttpd, repeated errors about the firewall's GUI certificate. After the first reboot I had zero connectivity to the firewall nor through to the Internet, there was no access to a terminal even directly, so connecting a keyboard I hit ctrl-alt-del and this time I at least had connectivity but the web GUI was still broken.


Reverted lighttpd back to 20.7.6 and regained access. Looking back through this thread I read about the Let's Encrypt CAs and did a mass tidy up, deleted the old CAs leaving just the new R3. Regenerated the firewall's certificate, assigned it and restarted the GUI. All was well.


I then from the terminal re-ran updates to get the latest lighttpd back on - after restarting the GUI again my browser complained the certificate was not secure. The update had reset the configuration of the GUI back to the self-signed certificate but also deleted the new LE certificate so I could not add it back. Had to regenerate it once again, reassign the new certificate and restart the GUI service. Tested a restart and things still work so I really hope I've now seen the back of this issue for future updates.


Things of note:

   
• HAProxy refuses to start complaining that certain servers cannot be found, caused by DNS service being slow e.g. using unbound + dnscrypt-proxy, as some of my sites use the fqdn for the back-end server names. Manual start afterwards fixes issues.
• There's a warning from lighttpd that "mod_compress" is soon to be deprecated and will cause future versions of lighttpd to fail to start. I'd post the log entry but cannot find anything under "/var/log" containing it, I only have a photo I took from the console screen.

is this going to be fixed someday?
after every update i keep getting this error ERR_SSL_PROTOCOL_ERROR and have to restore the opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart


i am at 20.7.8 now but the error still appeared.

Quote from: Julien on January 25, 2021, 10:40:37 PM
is this going to be fixed someday?
after every update i keep getting this error ERR_SSL_PROTOCOL_ERROR and have to restore the

Code Select Expand

opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart


i am at 20.7.8 now but the error still appeared.

As I did you need to double check all the certificates are valid - for me the one being used by the OPNsense GUI was generated by Let's Encrypt but was still using the old CA/Intermediate CA. When I deleted it and forced it to be renewed by LE, it then showed as signed by "R3" the new CA and the error did not come back when updated back to the latest version. Although as I also wrote the upgrade did delete the first certificate I renewed and replaced it with a self-signed one, so I has to force renew it again a second time and re-assign it.

Guys I am stuck at 21.1
the gui is gone again
when I try the opnsense-revert -r 20.7.6 lighttpd && configctl webgui restart it does fail I guess 20.7.6 won't works with 21.1
anyone got a suggestion to restore the box?

I'd like to point out you opened a new thread in Forums " 21.1 Production Series":
https://forum.opnsense.org/index.php?topic=21189.0

Also here:

https://github.com/opnsense/changelog/blob/61a2138a8ca2a12acabe80a6903e4aa6facc4368/doc/21.1/21.1#L46

Recover from bad certificate from console has never been easier.


Cheers,
Franco

I was able to upgrade from 20.7.8_4 to 21.1 without any issues this time, so for me clearing house on the all the CA and generated certificates for the old Let's Encrypt CAs sorted it out.

lighttpd developer here.   lighttpd developers generally fix issues very quickly IFF those issues are reported to the lighttpd developers at https://redmine.lighttpd.net/projects/lighttpd/issues

When configuring certificates in lighttpd, please include the intermediate certificates.  Let's Encrypt provides fullchain.pem, and that is the file that should be configured for lighttpd to use.

    ssl.privkey= "/etc/lighttpd/certs/www.example.com/privkey.pem"
    ssl.pemfile= "/etc/lighttpd/certs/www.example.com/fullchain.pem"


There is extensive documentation for how to configure lighttpd TLS modules:
https://redmine.lighttpd.net/projects/lighttpd/wiki/HowToSimpleSSL
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL

When a browser shows the Err_ssl_protocol_error (http://net-informations.com/q/mis/fix.html), it indicates the browser is no longer able to access or initiate the secured communication. There is no definite guide for managing this error. Follow given steps to resolve this error from Client side:

• Try correcting the system date and time.
• Try clearing Google Chrome browsing data.
• Try clearing your SSL State.
• Try disabling the QUIC Protocol.
• Try checking your antivirus settings.
• Try enabling all SSL/TLS versions. 

 
Also, this error is because of the following aerver side problems:

• Invalid SSL or SSL is untrusted (self-signed)
• SSL Not installed properly
• Old Technology or SSL/TLS version for encryption