-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FW 3.2.7 breaks custom web certificates #62
Comments
@therealpaulgg opened a new issue, your case is different from the RADIUS issue many people seem to see. You debugged that your root certificate is gone from keystore - that may be another hint in the direction that UniFiOS says "incorrect / incomplete chain -> trash it, put self-signed in". but as you wrote, root cause for trust being broken in cert store is unclear... I assume when you copy the certs manually and restart |
So I mentioned in my last comment that I ended up trying to fix my cert store manually by both re-adding my Root CA and intermediate CA (I didnt need this previously) ran openssl verify and it reported OK Yeah copied the certs manually and they are gone. Maybe if I try configuring RADIUS (I never bothered) it'll work? |
This one is a bit trickier to solve than the RADIUS one. Still not entirely sure what to do. I did some digging based on what @ouaibe had mentioned in the other issue, and I was only able to find this one entry: "unifiNetwork": {
"certificate": {
"crt": "CERT_HERE"
},
"controllerURL": "https://192.168.1.1:8443",
"enabled": true,
"informURL": "http://192.168.1.1:8080/inform",
"sitename": "default",
"uciAllowList": []
}, this CERT_HERE is also a base64 encoded value but does not decode the same way that the radius certificates do, so I am a bit confused. Tried searching for other configuration files and had no luck. There is one called Its like the implementation of RADIUS and the web certs are just completely different, and I'm not able to find where they are configured at. |
Looking at it, that certificate is in DER format (binary), not PEM. These are both interchangeable/convertible using the following commands: DER -> PEM PEM->DER So in theory, if you already have your local CRT file
Then validate the NEW file, the JSON content at |
This makes sense... only concern I have is where is the key? previously for web certs it needed both the cert and the key. You should need both pieces, right? |
A CRT file for a server can (should?) contain both the cert and the private key. You could try generating a regular CRT file in PEM format, that would contain the two sections:
And then convert that to DER and see if it works? Alternatively, you could try hacking a |
After digging a bit more, the Compared the output of This might mean that the keystore is used to back the signature for that part of the certificate management system. FWIW you can export the existing private key in
But I'm not sure how that private key would be useful for you, instead you could try adding your own private key/certificate to the existing keystore and see how it behaves with Good luck! |
Unfortunately it seems this certificate is completely different from the one on the web portal. Fingerprints dont match at all and the issuers are totally different ( I found a log in
wonder if the underlying cert implementations for unifi-core and the other stuff are just totally different. |
Ah, reading your message I had assumed the CRT in the JSON file was the right one, sorry to have mis-interpreted that. It's very likely they combine 3+ certificate management mechanisms, it seems to be all over the place between freeradius, the keystore (that must be used for something, maybe intra-Unifi comms over HTTPS), some certs for Protect and the unifi-core/Web UI stuff... One thing you "could" try, maybe to get more output out of Either way, if they are re-generating it, the private key and the cert must be somewhere... |
After being frustrated by 3.2.9's continuation of 3.2.7's bad behavior, I found this thread. I can confirm that marking both the cert and key immutable prevent them from being replaced upon restarting the unifi-core service. It's a kludge, but it'll do until a real fix comes along! |
Absolutely genius workaround...this totally solves my problem. Finally got around to actually implementing it on my Unifi router and its pretty straightforward. It is a little more complicated since I'm using Thank you very much, I had pretty much given up on the idea of accessing Unifi from a trusted domain at this point. |
Not sure this helps, but I'm on EA release v3.2.12 and all I had to do was place move the cert and key to /data/eus_certificates/unifi-os.crt and /data/eus_certificates/unifi-os.key respectively. |
@forrestrae interesting observation, have you ever used Glenn R.'s "UniFi Let's Encrypt" before? That script creates such directory. if you did not use it before, maybe UI has implemented that scripts mechanisms into firmware. |
Root CA
Intermediate CA
Router certificate
the router certificate is signed by my intermediate CA.
I just checked /etc/ssl/certs and looks like there's some stuff that has been deleted, including my root certificate from the keystore.
When I have some more time I'll play around with this...
Originally posted by @therealpaulgg in #61 (comment)
The text was updated successfully, but these errors were encountered: