Wildcard SSL Not Working for API Calls #14151
Replies: 3 comments 1 reply
-
|
Verification is done by the connecting client, comparing the name you referenced the server as with the name(s) in the certificate, to ensure it's talking to a legit server that has that name, so any troubleshooting you will do, aside from looking at the presented cert details (with a browser or openssl s_client -connect server:port / openssl x509 -text -noout -in certfile), will be done in your client app and looking at its configuration tunables for https/tls/ssl. it may not know about the Certificate Authority (CA) which signed your server's cert and needs to be configured to load an appropriate CA bundle, or maybe the hostname you are referencing when you connect is not covered by the wildcard in the cert (eg wildcard is for *.net.example.com but you asked for netbox.ns.example.com" which is an alias in DNS but not the same name), or you are using a bare IP address and thats not covered by the cert (eg. you asked for 192.168.0.1 and you got *.net.example.com, how can the client verify that?) (would need a subjectAltName for an IP and CAs can only verify public IPs that you own, they won't give you a cert saying you are the real 192.168.0.1 for example, for obvious reasons if you stop and think about it)
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: cameronpaulkpoint ***@***.***>
Sent: Tuesday, October 31, 2023 12:08 PM
To: netbox-community/netbox ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [netbox-community/netbox] Wildcard SSL Not Working for API Calls (Discussion #14151)
Hello, my organization uses Wildcard certificates for our Netbox instances, but I find API calls to them do not work.
The same API calls work for other instances, such as https://demo.netbox.dev, which uses a Standard SSL certificate issued to the hostname.
What is causing my API calls to fail against the wildcard certificate?
Error example: Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)')))
Please excuse my lack of SSL/TLS understanding :(
—
Reply to this email directly, view it on GitHub<#14151>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5TC4OX2OADM2L3LITYCEWAPAVCNFSM6AAAAAA6YBMXN6VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVG44TQNRWGU>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
This error suggests that it's nothing to do with being a wildcard certificate. The problem is that the client is unable to validate the signature; it hasn't got as far as checking the name in the certificate. There are various reasons you might get this error:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the explanations. What is the best practice in my situation?
…________________________________
From: Brian Candler ***@***.***>
Sent: Wednesday, November 1, 2023 5:39:47 AM
To: netbox-community/netbox ***@***.***>
Cc: Cameron Paulk ***@***.***>; Author ***@***.***>
Subject: Re: [netbox-community/netbox] Wildcard SSL Not Working for API Calls (Discussion #14151)
**CAUTION: External Email.**
unable to get local issuer certificate
This error suggests that it's nothing to do with being a wildcard certificate. The problem is that the client is unable to validate the signature; it hasn't got as far as checking the name in the certificate.
There are various reasons you might get this error:
* If you've made your own wildcard certs using your own CA, then the client has to be configured with the root CA certificate in order to do the validation. (You wouldn't get this problem using a Letsencrypt wildcard cert)
* Fixing this requires looking at your client code which calls the API, and adjusting it to pass the root CA certificate
* You don't see a problem for demo.netbox.dev because it's signed by a well-known CA, and the client already has the root CA certificate
* If there is a certificate chain involved, then the server has to be configured to serve both the end certificate and the intermediate certificate(s)
—
Reply to this email directly, view it on GitHub<#14151 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BDUYMQ37IRZJLO2R2N2AN6TYCIRHHAVCNFSM6AAAAAA6YBMXN6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TINBUGM4DC>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Talk to whoever issues the certificates in your organization. If your organization's policy is that you have a local CA to sign your own certificates, then you'll need to ask them for a copy of the root CA certificate, and you'll need to configure the client to use it when making a connection to the server. That is perfectly fine practice. Generating certificates from a well-known free public CA, like Letsencrypt or ZeroSSL, is also fine practice. Such certificates need to be renewed every 2-3 months; this generally means you need to configure automation on the server (e.g. certbot, dehydrated, certgrinder etc) to keep them up to date. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello, my organization uses Wildcard certificates for our Netbox instances, but I find API calls to them do not work.
The same API calls work for other instances, such as https://demo.netbox.dev, which uses a Standard SSL certificate issued to the hostname.
What is causing my API calls to fail against the wildcard certificate?
Error example: Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)')))
Please excuse my lack of SSL/TLS understanding :(
Beta Was this translation helpful? Give feedback.
All reactions