[Standalone PC] Display the expiration date for the site's certificate

[jmgrady]

There should be a way to display the expiration date for the NUC's SSL certificate - perhaps an About dialog which could also display a software version (if useful). There is an npm module for this - check-cert-expiration (https://www.npmjs.com/package/check-cert-expiration).

This can provide a good check as part of preparing a NUC to be sent to a workshop.

[jmgrady]

check-cert-expiration does not look as though it will work. I installed the module and ran the command line wrapper which said:

$ check-cert-expiration thecombine.languagetechnology.org
host=thecombine.languagetechnology.org port=443 valid_to=2020-10-09T12:00:00.000Z daysLeft=128

which is not correct - Let's Encrypt certificates are only good for 90 days. When I ssh to thecombine.languagetechnology.org and check the expiration date using openssl to look up the end date I get:

# openssl x509 -enddate -noout -in cert.pem
notAfter=Aug  1 13:58:07 2020 GMT

This could be o.k. - the certificate that expires in 128 days may be from Cloudflare rather than the server itself. Needs to be confirmed.

[jmgrady]

This feature only really makes sense on the NUCs, not the public servers.

[jmgrady]

Using the example on the check-cert-expiration page, the module is working correctly - it shows the correct expiration date for the NUC's certificate so the suspicious expiration date above is probably due to Cloudflare being the go-between for thecombine.languagetechnology.org. (I have not gotten it to work correctly yet in TheCombine application, though).

Another option is to have the backend publish the certificate expiration date. There are (at least) 2 ways that the backend can get this information:

1. look it up using the openssl x509 -enddate -noout -in cert.pem command. This requires that we add the combine user to an ACL for the certificate with read access. This is simple to do - we already do it on the public server so that the NUCs can synchronize their certificates without giving them root access.
2. Add a new collection to the database (DeviceStatus perhaps) and have the process that updates the certificate update a certificate expiration date in the DeviceStatus.

[jmgrady]

Note that the license for check-cert-expiration is not an MIT License. It claims to be functionally equivalent to the MIT License. I cannot say whether this is true or not.

[johnthagen]

The ISC license should be fine. As the GitHub text says, it's equivalent to MIT (permissive).

[jmgrady]

I'm not qualified to make that call.

It's one thing for the author to state that it is equivalent but an
IP attorney may not agree.

On 7/17/20 7:48 AM, johnthagen wrote:


  
  The ISC license should be fine. As the GitHub text says, it's
    equivalent to MIT (permissive).
  —
    You are receiving this because you authored the thread.
    Reply to this email directly, view it on GitHub, or unsubscribe.
  [

{ "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/sillsdev/TheCombine/issues/377#issuecomment-660064095", "url": "https://github.com/sillsdev/TheCombine/issues/377#issuecomment-660064095", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- 
  Jim
  "In practice, the difference between theory and practice is
    greater than it is in theory."

[johnthagen]

It's a pretty commonly used license. For example, the frontend already has 112 transitive dependencies using ISC license, so in my opinion having looked into this kind of thing for work before is that ISC should be fine. Someone from SIL legal is still welcome to look into it.

[jmgrady]

Thanks, that's helpful.

On 7/17/20 9:24 AM, johnthagen wrote:


  
  It's a pretty commonly used license. For example, the frontend
    already has 112 transitive dependencies using ISC license, so I
    my opinion having looked into this kind of thing for work before
    is that ISC should be fine. Someone from SIL legal is still
    welcome to look into it.
  —
    You are receiving this because you authored the thread.
    Reply to this email directly, view it on GitHub, or unsubscribe.
  [

{ "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/sillsdev/TheCombine/issues/377#issuecomment-660105387", "url": "https://github.com/sillsdev/TheCombine/issues/377#issuecomment-660105387", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- 
  Jim
  "In practice, the difference between theory and practice is
    greater than it is in theory."

[johnthagen]

If we see GPL or LGPL licenses, then we should raise a warning flag for sure as those have more ramifications. Though the ramifications are less for an open source project like Combine than a closed source commercial project.

[jmgrady]

See #1155.

[jmgrady]

The standalone installation supports this with the combinectl cert command.