SSL_ERROR_INTERNAL_ERROR_ALERT after restore to differetent machine

Hello and thank you for providing AIO.

It was time to move AIO from a pi to proxmox. Due to nfs and limitatins it resides in its own VM.

restoring went through successfully. The SSL certificates would still be valid, the backup was not too old. However, I cannot access nextcloud because of SSL_ERROR_INTERNAL_ERROR_ALERT. See the logs attached. acme challenge can not be successful, nextcloud is not live yet, the ports are not forwarded to the restored nextcloud on different IP.
I read this: What can I do when Nextcloud is not reachable via my domain or if I get `SSL_ERROR_INTERNAL_ERROR_ALERT` when opening my Nextcloud domain? · nextcloud/all-in-one · Discussion #2105 · GitHub . When I redirect port forwarding to the newly restored nextcloud issues might be gone.
Even this is maybe not an issue in AIO directly, I really would like to find a way to access Nextcloud to check if everything is running before I go live.

What could be a way for that?

the logs:

{"level":"error","ts":1696465808.270304,"logger":"tls.obtain","msg":"will retry","error":"[cloud.somedomain.de] Obtain: [cloud.somedomain.de] solving challenge: cloud.somedomain.de: [cloud.somedomain.de] authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":6,"retrying_in":1200,"elapsed":1217.05128199,"max_duration":2592000} {"level":"error","ts":1696467010.995993,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"cloud.somedomain.de","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]}} {"level":"error","ts":1696467010.996114,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"cloud.somedomain.de","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/120772574/11375032724","attempt":1,"max_attempts":3} {"level":"error","ts":1696467010.9962084,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"cloud.somedomain.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused"} {"level":"error","ts":1696467010.9963365,"logger":"tls.obtain","msg":"will retry","error":"[cloud.somedomain.de] Obtain: [cloud.somedomain.de] solving challenge: cloud.somedomain.de: [cloud.somedomain.de] authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":7,"retrying_in":1200,"elapsed":2419.777314575,"max_duration":2592000} {"level":"error","ts":1696468213.6871934,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"cloud.somedomain.de","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]}} {"level":"error","ts":1696468213.687327,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"cloud.somedomain.de","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/120772574/11375292354","attempt":1,"max_attempts":3} {"level":"error","ts":1696468213.6874402,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"cloud.somedomain.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused"} {"level":"error","ts":1696468213.6875544,"logger":"tls.obtain","msg":"will retry","error":"[cloud.somedomain.de] Obtain: [cloud.somedomain.de] solving challenge: cloud.somedomain.de: [cloud.somedomain.de] authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":8,"retrying_in":1800,"elapsed":3622.468532206,"max_duration":2592000} {"level":"error","ts":1696470016.8398833,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"cloud.somedomain.de","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]}} {"level":"error","ts":1696470016.8400183,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"cloud.somedomain.de","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/120772574/11375690734","attempt":1,"max_attempts":3} {"level":"error","ts":1696470016.840152,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"cloud.somedomain.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused"} {"level":"error","ts":1696470016.8402762,"logger":"tls.obtain","msg":"will retry","error":"[cloud.somedomain.de] Obtain: [cloud.somedomain.de] solving challenge: cloud.somedomain.de: [cloud.somedomain.de] authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":9,"retrying_in":1800,"elapsed":5425.621254402,"max_duration":2592000} {"level":"error","ts":1696471819.945788,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"cloud.somedomain.de","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]}} {"level":"error","ts":1696471819.9459233,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"cloud.somedomain.de","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"87.123.50.168: Connection refused","instance":"","subproblems":[]},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/120772574/11376205944","attempt":1,"max_attempts":3} {"level":"error","ts":1696471819.9460182,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"cloud.somedomain.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused"} {"level":"error","ts":1696471819.9461296,"logger":"tls.obtain","msg":"will retry","error":"[cloud.somedomain.de] Obtain: [cloud.somedomain.de] solving challenge: cloud.somedomain.de: [cloud.somedomain.de] authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - 87.123.50.168: Connection refused (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":10,"retrying_in":3600,"elapsed":7228.727107952,"max_duration":2592000} {"level":"error","ts":1696475423.1118526,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"cloud.somedomain.de","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:tls","title":"","detail":"87.123.50.168: remote error: tls: internal error","instance":"","subproblems":[]}} {"level":"error","ts":1696475423.1119783,"logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"cloud.somedomain.de","problem":{"type":"urn:ietf:params:acme:error:tls","title":"","detail":"87.123.50.168: remote error: tls: internal error","instance":"","subproblems":[]},"order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/120772574/11377222534","attempt":1,"max_attempts":3} {"level":"error","ts":1696475423.1120977,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"cloud.somedomain.de","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:tls - 87.123.50.168: remote error: tls: internal error"} {"level":"error","ts":1696475423.112212,"logger":"tls.obtain","msg":"will retry","error":"[cloud.somedomain.de] Obtain: [cloud.somedomain.de] solving challenge: cloud.somedomain.de: [cloud.somedomain.de] authorization failed: HTTP 400 urn:ietf:params:acme:error:tls - 87.123.50.168: remote error: tls: internal error (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":11,"retrying_in":10800,"elapsed":10831.893190079,"max_duration":2592000}

I would open the ports in order to resolve the SSL issue. I mean what can happen in the worst case? Either your Nextcloud is accessible afterwards, and works as expected, or it does not not, in which case you could close the ports again and investigate furter. Either way, I think it is very unlikely that you are going to expose your Nextcloud to a security risk because of this.

1 Like

well, thats what I did.

It’s not about security, for me it is about data integrity.
In my life as a hobby admin, no other thing gave me so much trouble as nextcloud. No one to blame, but I spent too many days and nights. So I would like to be careful.
In the end there is no chance test a new deployment. I moved to proxmox, which is running stable (so far). No test period possible, just one shot. Testing that before would be on my wishlist.

AIO is not designed to run completely air-gapped or with self-signed certificates, but I don’t see how that would stop you from testing it, or even have a separate test instance.

Sure, if you don’t want to expose a test instance to the internet, and / or if you have other VMs / Containers that you need to expose, it gets a bit more complicated, but it is possible: https://github.com/nextcloud/all-in-one/blob/main/local-instance.md

And if AIO doesn’t fit your needs, there are other ways to install Nextcloud, such as the “regular” Docker containers, Snap, NextcloudPi, The Nextcloud VM, or you could do a manual installation on a LAMP Stack in a Linux VM or a Linux Container, which is the most flexible way to host your Nextcloud, but also the one that requires the most effort.

1 Like