Title
#kolide
k

koba

07/21/2020, 8:28 AM
I'm not able to connect with fleet server due to
Failed enrollment request to <https://something.com/api/v1/osquery/enroll> (Request error: certificate verify failed) retrying
. I'm following FAQs to make sure I don't miss anything. Here is what i get when I curl the enroll endpoint.
❯ curl -v -X POST <https://something.com:443/api/v1/osquery/enroll>
*   Trying 13.234.113.134...
* TCP_NODELAY set
* Connected to <http://osquery.lalaland.com|osquery.lalaland.com> (13.234.113.134) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: <https://curl.haxx.se/docs/sslcerts.html>

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
8:28 AM
I'm not sure if i understand the significance of
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
sundsta

sundsta

07/21/2020, 6:18 PM
If it’s self-signed as indicated by your curl output, you need to specify the
--tls-server-certs
flag. See https://osquery.readthedocs.io/en/stable/installation/cli-flags/
k

koba

07/22/2020, 4:40 AM
Ahh, yes. It is self signed and I have already specified the
.pem
path in
--tls-server-certs
(The pem file downloaded form fleet web UI). I also cross checked that the fleet FQDN matches the CN in the
.pem
file. But I still can't enroll my client on fleet server. One thing I noticed is that openssl appends the
email
to the FQDN so the final CN in the certificate is
CN=<https://myfqdn/emailAddress=myemailid>
I hope that has nothing to do with the certificate failing to verify?
d

DG

07/23/2020, 5:39 PM
Probably unrelated, but finally got around to looking at my test environment and i had the Sectigo Cross-signed CA issue... Had to update all client certs...
5:40 PM
Secondly, some CA give the pem in a reverse order, and had to reverse in notepad the order to make work
t

tkrabec

08/13/2020, 1:51 PM
@koba did you have any luck in getting your issue fixed?
2:51 PM
NM got this working I used tls--server--certs and the .pem
k

koba

08/15/2020, 5:10 PM
Sorry I saw this and thought I replied but apparently I didn't. Yes I was able to fix it. I was generating certs with "https" included in the CN value. I dropped the https prefix and it worked. I'm not sure if this is right behavior though. Perhaps the error could be a little more clear? @zwass