<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <br>

    <div class="moz-cite-prefix">On 2/12/2016 11:37, R-D intern wrote:<br>

    </div>

    <blockquote cite="mid:1455298649401-63567.post@n7.nabble.com"

      type="cite">

      <pre wrap="">Thank you a lot, Jakob.I understood your answers and am quite satisfied too

that the replies sound conceptually right. But it would be kind on your part

if you answer some questions further.

1. Regarding question 3, I am using openssl 1.0.2e which supports named

curve. Such a question had earlier been asked in this forum which says ,

such a message is only misleading but the certificate works fine. Here is

the below

link:<a class="moz-txt-link-rfc2396E" href="http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047">"http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047"</a>.But

I would like the certificate have a clean structure. How can that be done?

2.Regarding question 7, I am working to secure a middleware that will be

deployed in control and monitoring systems, hence there would be know

persons at the client side and  the certificates I am  using are self signed

ones created using openssl 1.0.2e , hence there will be no public CAs . In

such a scenario , how will the CA know that the private  key has been

compromised? If the private key  gets compromised, then even the certificate

can be forged ,then what is the use of CRL?

 Kindly answer. 

Thanks and regards,

Suman Patro

</pre>

    </blockquote>

    <br>

    If the CA is private then the CA's public certificate (and any

    intermediates required to reach it) is loaded into OpenSSL as the

    chain of validation.  That certificate can specify an OCSP or CRL

    location for revocation checks, which you must then extract and

    check in your code.<br>

    <br>

    "Best practice" for something of this sort requires that <u><b>both</b></u>

    ends of the connection present and use certificates, not just the

    server (in other words you don't want a random client machine

    connecting either!) which in turn means you need to check for

    validity and revocation on both ends, <i><b>and </b></i>you must

    ensure the security of the CA infrastructure and its private key.<br>

    <br>

    Note that "how the CA knows the client private key is compromised"

    is an <i>operational </i>question, not a programmatic one -- as is

    the case with a public CA.  (In other words someone has to tell the

    CA it was stolen so the CA can issue the revocation, and the

    application must check that revocation resource.)<br>

    <br>

    <div class="moz-signature">-- <br>

      Karl Denninger<br>

      <a href="mailto:karl@denninger.net">karl@denninger.net</a><br>

      <i>The Market Ticker</i><br>

      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font>

    </div>

  </body>

</html>