I wasn't fully able to produce a CBOR file with the module yet (like mentioned in a previous issue), but in the current phase of my testing I want to mention two important topics.
First, the ngx_http_cert_chain_handler :
- It should be documented/mentioned this handler does the refreshing of the CBOR file only when a request to the CBOR file is issued. Which is logical, you only need to refresh it when it is requested. But it should be clear that this is not a periodic refresh or whatever. If no one is sending requests to that specific file given in
sxg_cert_url, nothing touches that file. But I understand it, and it is logical.
- There is this string check in the cert_chain_handler:
if (slc->cert_path.len <= 0 || req->uri.len != slc->cert_path.len || ngx_memcmp(req->uri.data, slc->cert_path.data, req->uri.len) != 0) { return NGX_OK; }
As an explanation to the untrained eyes, this function makes sure that CBOR refresh code never runs, if the CBOR file is not the one being requested (as stated above). But it does so, by comparing the absolute path given in sxg_cert_path and request URI (if these strings are the same, it is considered a request to the CBOR file).
Something like this:
The absolute path of the file:
sxg_cert_path /mnt/server_documents/certificates/customer_id_346512/sxg/document.cbor
The way this module asks for it to be delivered.
www.website.com/mnt/server_documents/certificates/customer_id_346512/sxg/document.cbor
In other words, you have to put the entire directory structure in the link, and serve it that way. Although not impossible, I find this approach a bit forcing. It was also undocumented, and had to go through the code to understand why anything wasn't refreshed(or tried to be refreshed) and my SXG's were invalid after some time. I was just serving the CBOR file in a different URI. And the string comparison returning False, prevented the code from being executed. There could be many possible ways to improve this, so it's an open debate. Even without an improvement, documenting the current behavior would certainly clarify things.
Secondly, logging of refreshing:
- As an example, here:
bool refreshed = refresh_if_needed(&slc->cert_chain); if (refreshed) { ngx_log_error( NGX_LOG_INFO, req->connection->log, 0, "nginx-sxg-module: OCSP Response in Certificate-Chain is refreshed"); }
It is logged only when CBOR refresh is needed and successful. A failure log is just as needed, with explaining the failure reason (OCSP error, file permission error etc...). Without fail log, the CBOR could be expiring without an alert.
The reason I primarily inspected sxg_cert_path is that it is such a fundamental feature of the module. SXG simply doesn't work without it. Even though there is an alternative for it (gen-certurl), it could be more appropriate for people to do without any 3rd party tool, which brings something other than nginx to maintain/monitor.
It also takes like seven days for the CBOR to expire, making the tests very slow, and failure unapparent (You don't know if it's failing). So at least the documentation is paramount.
Thanks for your time, and your good work. Have a nice day.
I wasn't fully able to produce a CBOR file with the module yet (like mentioned in a previous issue), but in the current phase of my testing I want to mention two important topics.
First, the
ngx_http_cert_chain_handler:sxg_cert_url, nothing touches that file. But I understand it, and it is logical.if (slc->cert_path.len <= 0 || req->uri.len != slc->cert_path.len || ngx_memcmp(req->uri.data, slc->cert_path.data, req->uri.len) != 0) { return NGX_OK; }As an explanation to the untrained eyes, this function makes sure that CBOR refresh code never runs, if the CBOR file is not the one being requested (as stated above). But it does so, by comparing the absolute path given in
sxg_cert_pathandrequest URI(if these strings are the same, it is considered a request to the CBOR file).Something like this:
The absolute path of the file:
sxg_cert_path /mnt/server_documents/certificates/customer_id_346512/sxg/document.cborThe way this module asks for it to be delivered.
www.website.com/mnt/server_documents/certificates/customer_id_346512/sxg/document.cborIn other words, you have to put the entire directory structure in the link, and serve it that way. Although not impossible, I find this approach a bit forcing. It was also undocumented, and had to go through the code to understand why anything wasn't refreshed(or tried to be refreshed) and my SXG's were invalid after some time. I was just serving the CBOR file in a different URI. And the string comparison returning False, prevented the code from being executed. There could be many possible ways to improve this, so it's an open debate. Even without an improvement, documenting the current behavior would certainly clarify things.
Secondly, logging of refreshing:
bool refreshed = refresh_if_needed(&slc->cert_chain); if (refreshed) { ngx_log_error( NGX_LOG_INFO, req->connection->log, 0, "nginx-sxg-module: OCSP Response in Certificate-Chain is refreshed"); }It is logged only when CBOR refresh is needed and successful. A failure log is just as needed, with explaining the failure reason (OCSP error, file permission error etc...). Without fail log, the CBOR could be expiring without an alert.
The reason I primarily inspected
sxg_cert_pathis that it is such a fundamental feature of the module. SXG simply doesn't work without it. Even though there is an alternative for it (gen-certurl), it could be more appropriate for people to do without any 3rd party tool, which brings something other than nginx to maintain/monitor.It also takes like seven days for the CBOR to expire, making the tests very slow, and failure unapparent (You don't know if it's failing). So at least the documentation is paramount.
Thanks for your time, and your good work. Have a nice day.