Point 2 and 3 already in place. will figure 1 out quickly
G
1 Like
Good…then you only need to figure out step 1… shouldn’t be too hard 
done…
General settings.
G
Then this should be working now in IOS:
local: https://my.domain.url:8123
external: https://my.domain.url
And I am not sure if PFSense support HairPin NAT, but if that is the case, then there would be no need to differentiate between internal and external URL’s on IOS
PS: in order for IOS to differentiate between internal and external you will need to define your wifi SSID’s
so just noticed at the url, even though there seems to be something wrong with everything (my side)… even in the browser, it’s showing site is not trusted (and a accept risk is registered)… so that aligns up with iOS complaining about the cert.
and yes I’ve re-issued by lets_encrypt cert.
will have to redo the cert setup completely.
G
strange though as in ACME configuration my key and the certs have tick boxes as valid.
G
- Are you sure it’s the letsencrypt that is used (in a browser, click on the padlock and find your way to “view certificate”). Check if you can see why the certificate is not trusted
- Are you using a Full Qualified Domain Name for your certificate of a “wildcard” (“*.mydomian.com”) one
- Are you calling HA with the exact same FQDN
P.S. That’s your problem, btw. You cannot create an “accept risk exception” in the app.
- Yes
- FQDN
- Yes
and agree on the iOS risk accept which we can’t so I need to get it first in the browser working without a risk acceptance, if I get that working then the app should just work… we hope
G
Yeah, so check in a browser why exactly the certificate is not trusted.
If it’s something about a X1 certificate being expired, we’re in the case I exposed above.
Mine (using chrome browser:
for the life of me I don’t know whats wrong where… I’ve now double triple check everything…
Certificates are issues, account keys are valid. but it still fails. atm it does not even want to get to my sites.
now getting a 503.
G
… feels like I’m going backwards…
can understand why some people just say f it and keep with duckdns.
G
Well, as said above, you’re pilling up point of failures on tools I’m not sure you tamed…
If you are using Cloudflare for your domain, why don’t you use the free certificate offered by Cloudflare ?
… so I created my lets_encrypt with 3 subdomains defined, so that I can configure a shared front end in haproxy.
got the one sub domain working which simply replies with whoami information.
the second subdomain thats the ha. does not want to work… responding with a 503.
G
correct, this is new to me… so frustrating if you follow a example to the tee and it does not work and you don’t have a clue how to figure out whats actually causing the problem.
G
See Direct Msg.
G
From a guy who basically spent his whole life learning new tricks:
Examples are good and even mandatory, but are worthless if you don’t understand what they are doing
First, don’t expect your whole setup to work at once.
Isolate the components and test them separately, from bottom to up.
In you instance:
- Start by ensuring you pfSense setup is working, from your LAN
- Then try to go through internet without cloudflare
- Then finally add cloudflare
… and this is who I created a little docker image, that runs a whoami web server,
I then made sure I can get to it from internal to my network… works.
Got this working yesterday, just never noticed it was because I “accepted” a risk.
Got it working NOW, all secured, using my certs.
now onto Hime Assistant.
both are defined as sub domains in haproxy, using a shared frontend configuration.
G
You already learned something: If you are presented with a “accept the risk” prompt in your browser, your SSL setup is NOT correct 