It's not so much wanting to be a CA but we do need to move into SSL/TLS secured services. We could use self-signed certificates but I do like the idea to have a single root certificate that is used for all our VM, VSE and Linux certificates. This way we only need to import the root CA once and all servers will then be accepted.
Indeed there are applications that tend to go towards rejecting a certificate when the status of the certificate cannot be validated. So it looks like an OCSP responder should be something that might be required in the future. I have created a certificate for a server. Next I start the openssl ocsp responder. But the test gives "intermediate/certs/nlzlx118_ip.cert.pem: unknown". This certificate should be known so I don't understand why the responder gives this result. Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van Sleeuwen Flight Forum 3000 5657 EW Eindhoven -----Original Message----- From: Linux on 390 Port <[email protected]> On Behalf Of Alan Altmark Sent: Friday, June 21, 2019 1:02 AM To: [email protected] Subject: Re: Building a Certificate Authority On Wednesday, 06/19/2019 at 12:01 GMT, "van Sleeuwen, Berry" <[email protected]> wrote: > My first question is what to do with OCSP? Do I really need ocsp for > my purpose? I have found some mixed views on that. Some browsers have dropped CRL > support but otoh chrome doesn't use ocsp. So instead of investigating the > issues with ocsp should I just drop it and do without ocsp? OCSP is replacing CRLs. If you're going to be a CA, *be* a CA. If you're just playing around, then no worries. > And secondly, if I should setup ocsp, what might be the catch that prevents me > from a successful validation? Your oscp responder service not being available 24x7. For now, the policies dealing with the lack of ocsp and/or crl tend toward "assume it's ok". Kinda loosey goosey. I don't know for how much longer, though. But it will depend on what the client side is willing to tolerate. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7Cc66b56d3832d41b1471408d6f5d38622%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C636966686170761012&sdata=RdQgNDw06g1BYl0APirOgU1l0QOHtsSMYOnp5y%2BEVCc%3D&reserved=0 This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, Atos’ liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
