Adding my cents here; recently Apple's Safari announced the browser will not accept certificates which expire later than 1 year ahead. Chrome will follow a similar approach. https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/ https://www.thesslstore.com/blog/google-chrome-to-join-apple-safari-in-one-year-certificate-validity/
These are different use-cases, but I guess it'll affect the whole industry standard to *avoid* long-lasting certificates. -----Original Message----- From: [email protected] <[email protected]> On Behalf Of ZWARICO, AMY Sent: Wednesday, July 1, 2020 2:49 AM To: Krzysztof Opasiak <[email protected]>; [email protected]; 'Pawel Pawlak' <[email protected]>; DESBUREAUX Sylvain TGI/OLN <[email protected]>; ROUZAUT Fabian TGI/OLN <[email protected]> Cc: Geissler, Andreas <[email protected]>; Closset, Christophe <[email protected]>; ROSE, DANIEL V <[email protected]>; Lefevre, Catherine <[email protected]>; PLATANIA, MARCO <[email protected]>; FREEMAN, BRIAN D <[email protected]>; [email protected]; [email protected]; [email protected]; Kuzmicki, Krzysztof (Nokia - PL/Wroclaw) <[email protected]>; [email protected]; [email protected] Subject: Re: [onap-discuss] [ONAP] [Guilin] [SECCOM] [Integration] check certificates, open questions and result table and success criteria *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Nice report! Question 1: I'd like to see both, but if you only keep one, I agree with Krzysztof that it should be the date Question 2: Cert expiration - one year certs for ONAP out of the box. Industry best practices say 2years max for client or server certs, and in practice organizations generally renew after one year. Roots and intermediates can last a lot longer. Yes, Krzysztof, there are use cases for more frequent renewals: days, hours, minutes; ONAP out of the box doesn't need that. Question 3: +1 Question 4: Keep the error table Question 5: success criteria => expiration date + root CA (again, industry best practice says you check both expiration date and root) Question 6: xfail list => yes Question 7: I can't think of anything else, but when you are at your busiest, I'll ask you to add something. It's what I do best. -----Original Message----- From: Krzysztof Opasiak <[email protected]> Sent: Tuesday, June 30, 2020 12:59 PM To: [email protected]; ZWARICO, AMY <[email protected]>; 'Pawel Pawlak' <[email protected]>; DESBUREAUX Sylvain TGI/OLN <[email protected]>; ROUZAUT Fabian TGI/OLN <[email protected]> Cc: Geissler, Andreas <[email protected]>; CLOSSET, CHRISTOPHE <[email protected]>; ROSE, DANIEL V <[email protected]>; LEFEVRE, CATHERINE <[email protected]>; PLATANIA, MARCO <[email protected]>; FREEMAN, BRIAN D <[email protected]>; [email protected]; [email protected]; [email protected]; Kuzmicki, Krzysztof (Nokia - PL/Wroclaw) <[email protected]>; [email protected]; [email protected] Subject: Re: [ONAP] [Guilin] [SECCOM] [Integration] check certificates, open questions and result table and success criteria Hi, On 30.06.2020 17:02, [email protected] wrote: > Hi, > > I updated the test to verify the certificates: > https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r > _c_integration_-2B_109207&d=DwID-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=PJ-KGa4e > srIcYgd1dEzHLA&m=GIWK9IfQTwItnf0yBoeIsBe9GoBeauvx8pgIPoYYMqY&s=ZgI6beA > aU0gcdk2E_fHAvtTsP-yg1WsW4xCNl97SAYI&e= > <https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye > .com_url-3Fk-3D6e831ab1-2D3357a6d9-2D6e8291fe-2D0cc47a3356b2-2D9f03ccf > daa554d41-26q-3D1-26u-3Dhttps-253A-252F-252Fgerrit.onap.org-252Fr-252F > c-252Fintegration-252F-252B-252F109207&d=DwID-g&c=LFYZ-o9_HUMeMTSQicvj > Ig&r=PJ-KGa4esrIcYgd1dEzHLA&m=GIWK9IfQTwItnf0yBoeIsBe9GoBeauvx8pgIPoYY > MqY&s=BFHWSzBjUL1TKvlweD5webTyV04P5hXNWJt-Vs8pdM8&e= > > > I see 3 possible "modes": nodeports, internal and ingress > > for the moment I worked the nodeport mode, you will find attached the > results of the test on the daily frankfurt. > I have some questions for SECCOM/OOM. > > For this test, I retrieve all the ONAP services from the kubernetes > client, then for each service I give a try to the nodeport. > then at the end I build a table, the main table includes the following > fields Component = service name | Port = node port | Expiration date > | Remaining days | Cluster IP = cluster IP associated with the node > port | Root CA = info got from the certificate issuer | Root CA > Validity > > The other tables below correspond to specific errors (SSL, > connection,..), I do not consider them as error criteria as the test > being executed from outside the cluster, it is usually logical to get > the error but I prefer to keep a trace in a table. > I should be able to test these ports in internal mode later. > > *Question 1*: Expiration date and Remaining days are redundant: shall > I keep the 2 columns or keep only the remaining days? I'm a stupid guy so I'll argue with Sylvain and Fabian and say that we should keep certificate expiration day. Why? Because if someone runs the test around midnight one part of certificates may have "90 days to go" and the other part "89 days to go" which I expect may cause our tests to fail;) > > I do consider 2 parameters for the test success criteria > - the certificate remaining days I'd replace this with "expected expiration date" because of the reason above. > - the root CA validity +1 > > The color code is as follow and can be easily amended if you have any > recommendations or design advices > > remaining days > > 1000 => line is light blue > *Question 2*: 1000 is totally arbitrary, what is the recommendation to > say that the certificates is probably too long > 365 > 1000 > ? It all depends who you ask. If admin then there is no such thing as a too long valid certificate xD If security expert then probably 10 minutes could be too long. Fortunately I'm non of those so I'd opt for the middle ground suggested by Sylvain base on major browsers. > 30< expiration < 60 => line is orange > expiration < 30 => line is red light > = 364 (+ Root CA OK) => line is green light => it corresponds to > auto-generated certificates > no color in any other case > > *Question 3*: are you OK with the color code? + 1 > > *Question 4*: Shall I keep the error table or is it misleading > > root CA > if I got C=US;O=ONAP;OU=OSAAF;CN=intermediateCA_9 => I consider the Root > CA as OK => Validity is a green square > if not => red circle > > Both indicators are independent > we can be red with a good certificate Root CA and we can be green and > have a red circle if the certificate is still valid but the Root CA not > correct > > At the end the success criteria is False is 1 of the certificate is > under 30 days or Root CA are not correct. > It means that it will be FAIL until everything is fxed.. I'd keep it as it brings some useful information. > > *Question 5*: success criteria => only expiration date or expiration > date + root CA? both > > *Question 6*: shall we plan a xfail list here? yes. Empty for now but I expect that closer to the release we get more "exception requests" we'll see. > > *Question 7*: Note I added the Cluster IP for information, any other > info you would like to see in the table? How about having a direct mapping to pod/service name instead of cluster IP to make it easier for project teams to notice "hey it's my on that list I need to do sth with it" > > I started working on the integration in CI > Once open questions clarified, the code in integration repository will > be merged > I will create a xtesting docker (I did already one quickly in > gitlab.com, I will create a new patch in ONAP as xtesting and its > associated docker build chain has be reintegrated in ONAP repositories) > I put this test in the infra-healthcheck docker (was almost ready from a > dependency perspective) > > +--------------------------------+------------------+------------------+----------------+ > | TEST CASE | PROJECT | DURATION | RESULT | > +--------------------------------+------------------+------------------+----------------+ > | nodeport_check_certs | security | 00:02 | FAIL | > +--------------------------------+------------------+------------------+----------------+ > > > Once the new docker would be created, the test will be automatically > run, I would 'just" need to adapt the dashboard to display the result of > this test (daily and gating) > > /Morgan > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21566): https://lists.onap.org/g/onap-discuss/message/21566 Mute This Topic: https://lists.onap.org/mt/75215203/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
