Public OSSKB API not working (SSL + Missing/Invalid file errors) – scanoss-py integration failure

[chraghunadh]

Description

We are integrating scanoss-py in our CI environment for automated scanning and SBOM generation, FOSS.

Currently, the OSSKB public API is not working in our setup. We are facing multiple issues depending on the method used.

---

Issue 1 – SSL Error (scan command)

Command used:
scanoss-py scan . --format cyclonedx --output sbom.json

Error:
SSLError: HTTPSConnection ... certificate verify failed

We also tested after adding corporate root certificate, but the issue persists.

---

Issue 2 – Direct API upload (WFP)

Generated WFP:
scanoss-py wfp . -o output.wfp

Verified file:

• File exists
• Not empty
• Generated using latest scanoss-py

Curl command used:
curl -X POST "https://api.osskb.org/scan/direct"
-H "Content-Type: application/octet-stream"
--data-binary "@output.wfp"

Response:
{"error":"Missing or invalid file"}

---

Network Testing

• Tested from corporate internal network
• Tested from external ISP (non-corporate network)
• Same behavior in both environments
• No proxy blocking observed
• No firewall rejection message

---

Observations

**- Public OSSKB endpoint may have changed

• Possibly authentication/API key is now required
• Documentation does not clearly mention current requirements
• Both scan command and direct upload fail**

---

Environment

OS: Windows 11
Python: 3.13
scanoss-py: (run scanoss-py --version)
Usage: CLI integration for automated SBOM generation and FOSS

---

Questions

1. Is the public OSSKB API still available for anonymous usage?
2. Is API key now mandatory?
3. Has /scan/direct endpoint changed?
4. Is there updated documentation for current API usage?

Kindly clarify the correct integration method.

Thank you.
Raghu.

[isasmendiagus]

Hi @chraghunadh, thanks for the detailed report.

To answer your questions upfront: yes, the public OSSKB API (https://api.osskb.org) is still available for anonymous usage — no API key is required, and the /scan/direct endpoint has not changed.

Let me address both issues:

Issue 2 — {"error":"Missing or invalid file"} (curl)

The /scan/direct endpoint expects a multipart form upload with a field named file. Your curl command sends the data as a raw binary stream (--data-binary with Content-Type: application/octet-stream), which is why the server responds with "Missing or invalid file".

Fix — use -F instead:

curl -X POST "https://api.osskb.org/scan/direct" \
  -F "file=@output.wfp"

This sends the file as multipart/form-data with the correct file field name, which is what the API expects.

Issue 1 — SSL certificate verification failure

Since you mentioned a corporate environment, this is most likely caused by a corporate proxy or firewall performing TLS inspection (MITM), which replaces the server's certificate with one signed by your corporate CA. The default Python certificate bundle doesn't trust that corporate CA, so the SSL handshake fails.

Troubleshooting steps:

1. Confirm it's a cert issue by temporarily bypassing verification:

   scanoss-py scan --ignore-cert-errors -o results.json .

   If this works, the root cause is definitely certificate-related.

2. Download the server certificate as seen from your network:

   scanoss-py utils cdl -n api.osskb.org -o api-osskb-org.pem

3. Use the certificate with your scan:

   scanoss-py scan --ca-cert api-osskb-org.pem -o results.json .

4. Alternatively, set environment variables (useful for CI pipelines):

   export REQUESTS_CA_BUNDLE=/path/to/cert.pem
   export GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=/path/to/cert.pem
   scanoss-py scan -o results.json .

   If your corporate CA certificate is already available on the system (e.g., in /etc/ssl/certs/), you can point these variables to it directly.

For more details, see the Certificate Management section in CLIENT_HELP.md.

Debugging

If you still run into issues, add the -d (debug) flag to get verbose output that can help pinpoint the problem:

scanoss-py scan -d -o results.json .

Feel free to share the debug output (redacting any sensitive info) and we can help further.

[eeisegn]

please re-open if you still have issues.