Re: [Pki-devel] ACME Support: Error issuing certificate
- Original Message - > > Hi - > > > > My team is adding ACME 2.0 client support to the Open Liberty application > > server and wanted to test against Dogtag PKI's ACME server. My intention is > > to containerize the ACME server and drive it through the same functional > > tests we run against other ACME CA servers (i.e. - Pebble and Boulder for > > instance) to verify compatibility. > > > > The first error I hit was an issue with using JSS 4.7 and I understand that > > will be fixed by PR https://github.com/dogtagpki/jss/pull/532 . > > > > [snip] > > > > To move past this error, I was advised to move down to JSS 4.6.2. Upon > > doing > > so, I made it past the initial error but now hit the following error: > > > > [snip] > > > > I can see in the ACME server's trace that it does indeed authorize my > > ownership of the domain and then try to issue the certificate. Examining > > the > > AcmeIssuer class shows that this class has several methods that are not > > implemented. > > > > https://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/dogtagpki/acme/issuer/ACMEIssuer.java#L61 > > Is this expected or is it possible I have a misconfiguration? I assume I am > > testing too early and need to wait until the implementation is further > > along, but I wanted to test early enough that if there were issues I could > > detect them earlier rather than later. > > > > If it matters, I am testing the with the image from @pki/master on a Fedora > > 30 docker container. > > Hi Jesse, > > Thanks for your interest on Dogtag PKI and particularly the ACME responder. > Please note that the ACME responder itself is not a CA; it requires another > CA to issue the certificates. Currently the only supported CA is Dogtag PKI > CA which is connected through PKIIssuer: > https://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/dogtagpki/acme/issuer/PKIIssuer.java > > The ACMEIssuer is just a base class. It's possible to support other CAs > by extending ACMEIssuer. If you would like to add support for another issuer > upstream feel free to submit a pull request. We have a prototype for OpenSSL > that we might add later. > > The issue with JSS is correct, and we're still working to fix it. > > The unimplemented ACMEIssuer issue seems to be caused by a missing CA. Please > follow these docs to install 389 DS, then install Dogtag PKI CA: > https://www.dogtagpki.org/wiki/Installing_DS > https://github.com/dogtagpki/pki/blob/master/docs/installation/Installing_CA.md > > Then follow these docs to install and verify ACME: > https://github.com/dogtagpki/pki/blob/master/docs/installation/Installing_ACME_Responder.md > https://github.com/dogtagpki/pki/blob/master/docs/user/Using_ACME_Responder.md > > Officially we do not support containerization yet, but it's possible to run > ACME, CA, and DS in containers under some scenarios. > > If you run Fedora 30 as a local Docker container, you can execute commands in > the container to install ACME, CA, and DS like regular Fedora applications. > > However, if you want to run each of them as a single process in separate > Docker containers, it is possible with some code changes and tricks: > https://www.dogtagpki.org/wiki/PKI_ACME_Container > https://www.dogtagpki.org/wiki/PKI_CA_Container > https://www.dogtagpki.org/wiki/DS_Container > > Similarly, here are the docs for OpenShift deployment: > https://www.dogtagpki.org/wiki/PKI_ACME_OpenShift > https://www.dogtagpki.org/wiki/PKI_CA_OpenShift > https://www.dogtagpki.org/wiki/DS_OpenShift > > Please note that the wiki is used for development, so the content might be > outdated. The official docs are on GitHub. > > The ACME responder is easier to containerize. We might be able to officially > support its containerization soon. However, the CA might be more difficult > due to its dependency on systemd and other issues. The DS seems to require at > least some code changes. > > If you want to test ACME containerization, you probably can install ACME > in container with CA and DS running on the host machine. If you just want > to test ACME compatibility without containerization, it might be best to > install ACME, CA, and DS on regular machine for now. > > Hope this helps. Let me know if you have any question. > > -- > Endi S. Dewata Hi Jesse, I was just wondering if you managed to test against the ACME server. FYI, we're working on adding an embedded CA into the ACME server so it can be containerized more easily without dependency on a separate CA. Hopefully we will have something usable by the end of the month. -- Endi S. Dewata ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] Certificate Transparency SCT signature verification?
Hi Christina,
Adding pki-devel@ for wider audience. Comments below.
On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote:
> Hi Fraser,
> Do you know how the signature returned in the SCT response could be
> verified by the CA?
> My thought is that the CA should somehow verify the CT response after
> sending the add-pre-chain request and before signing the cert. Since log
> inclusion verification would not be feasible right after the request (the
> SCT response is supposed to be just a "promise, according to the rfc), I
> ruled that out and intend to stay with just the following two verifications
> on the response itself:
>
>- checking if log id (CT log signer public key hash) returned in the CT
>response is correct
>- this I have no problem verifying
> - Verifying if the signature returned in the CT response is correct
> - this I can't seem to get it working.
>
> I put the verification work above in the method "verifySCT".
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209
> What I am wondering is how this can be done properly. Since the tbsCert is
> not to contain the poison extension, the poison extension needs to be
> removed by the CT server before it signs. What if the order of the
> extensions contained in the tbsCert gets changed in the process?
>
The poison extension must be removed, and care must be taken to keep
everything else in the same order, and reserialise the parts in
exactly the same way.
> It seems that the response should contain the tbsCert that it signs (which
> isn't per the rfc) or I am not sure how the CA could verify the signature.
>
The response does not contain the TBCCertificate. Both sides (log
and client) remove the poison extension (and change nothing else),
then both sides can sign the same data.
> So the question now is if I should just leave out the check, unless you
> have other suggestions.
>
I do think we should verify the signature, to ensure the message was
actually received by the log server we wanted and not an impostor.
> Of course, I also could have missed something in my code.
>
The binary format is complex and it's easy to miss something. After
you implement removal of the poison extension, if it is still not
working I will go over the code with a fine-tooth comb.
I copied some of the code and left comments below, too. Comments
begin with `!!'. I think I found one bug and a couple of possible
improvements.
> One last question, currently in the code, if verifySCT fails, I just
> "continue" to process for next CT log. Should this just bail out all
> together or it's fine to continue? Or could this be a choice by the admin.
> What do you think and why?
> https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L951
>
My line of thinking is this:
- we should tolerate communication errors with log (perhaps
enqueuing the cert for a retry later)
- but (assuming we implement it correctly) verifySCT failure is
indicative of something wrong with the log (e.g. key changed); it
is not a communication error and can be treated differently.
- I think it's OK to fail hard. Admins will likely want to know if
something is wrong with CT logging.
- But in case we make a mistake, or an org needs issuance to
continue despite CT log misbehaviour, there should be a config
knob to allow this condition to be ignored. "In case of
emergency..."
>
> thanks,
> Christina
boolean verifySCT(CTResponse response, byte[] tbsCert, String logPublicKey)
throws Exception {
/* ... SNIP ... */
byte[] extensions = new byte[] {0, 0};
!! although no extensions have been defined I think we should we take
extensions from the CT response to future-proof this code. i.e.
decode the base64 data from the "extensions" field, and prepend the length.
// piece them together
int data_len = version.length + signature_type.length +
timestamp.length + entry_type.length +
issuer_key_hash.length + tbsCert.length + extensions.length;
logger.debug(method + " data_len = "+ data_len);
ByteArrayOutputStream ostream = new ByteArrayOutputStream();
ostream.write(version);
ostream.write(signature_type);
ostream.write(timestamp);
ostream.write(entry_type);
ostream.write(issuer_key_hash);
ostream.write(tbsCert);
!! I believe you need to prepend the length of tbsCert as a
THREE-byte length field, because its definition is
`opaque TBSCertificate<1..2^24-1>;'
ostream.write(extensions);
byte[] data = ostream.toByteArray();
// Now, verify the signature
// Note: this part currently does not work; see method comment above
// cfu ToDo: interpret the alg bytes later; hardcode for now
Signature signer = Signature.getInstance("SHA256withEC", "Mozilla-JSS");
Re: [Pki-devel] Configuration of Friendly Name and Country
Hi Nadeera, Please find my reply inline On Fri, May 29, 2020 at 5:28 AM Nadeera Galagedara < nadeeragalaged...@yahoo.com> wrote: > Dear Dinesh, > > I tried the method and still have the problem. I will tell you what i did > and can you tell me where did I do wrong. > > My root CA has "*Maximum number of intermediate CAs: unlimited*" and now > I am installing the issuing ca (what I use for to issue certificates for > clients). For the issuing *CA **Maximum number of intermediate* CAs want > to be *Zero*. > > I basically follow > https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_with_External_CA_Signing_Certificate > steps > (send the CSR to root CA and get back the signed certificate) and added > > policyset.caCertSet.5.default.name=Basic Constraints Extension Default > policyset.caCertSet.5.default.params.basicConstraintsCritical=true > policyset.caCertSet.5.default.params.basicConstraintsIsCA=true > policyset.caCertSet.5.default.params.basicConstraintsPathLen=0 > > lines to both step 1 and step 2 config files and installed the Issuing CA. > The above lines need to be added to profiles, not to .cfg for pkispawn. My colleague, Fraser, wrote an awesome blog post [1] explaining how Dogtag profiles work. Though the post was written in 2014 this should give you a good understanding of how to configure profiles. But, in your case, I believe you need to craft the CSR with this constraint. So, you need to use the `openssl` or `certutil` tools to specify the *basic Constraint*. For example, using openssl: openssl req \ -addext basicConstraints=critical,CA:TRUE,pathlen:1 \ ... You can also refer how to create CSR in our wiki [2] [1] https://frasertweedale.github.io/blog-redhat/posts/2014-05-14-dogtag-profile-definitions.html [2] https://www.dogtagpki.org/wiki/Generating_CA_Signing_CSR_with_OpenSSL HTH. Good luck! Regards, --Dinesh > Then I went to the Issuing CA's * "SSL End Users Services" *-> "*Manual > User Dual-Use Certificate **Enrollment"* and created a certificate. Then > I wend to *Agent Services* and approve that request. > > I imported that certificate to browser. But still it shows my issuing CA > *Maximum > number of intermediate CAs: unlimited. * > > Can you tell me what did I do wrong. > > > On Friday, May 22, 2020, 11:27:29 PM GMT+5:30, Dinesh Prasanth Moluguwan > Krishnamoorthy wrote: > > > Nadeera, > > (CC'ing pki-devel) > > Setting the number of intermediate CAs can be achieved by using "Basic > Constraints Extension" [1] and setting the PathLen= to the required value. > > You need to set this extension on a CA profile and then issue a CA signing > cert. You can't modify this value on an already issued CA cert. Read more > on how to add this constraint to a profile here [2] > > [1] > https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#Basic_Constraints_Extension_Default > [2] > https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#about-extensions > > Regards, > --Dinesh > > On Fri, May 22, 2020 at 8:57 AM Nadeera Galagedara < > nadeeragalaged...@yahoo.com> wrote: > > Dear Dinesh, > > I want another help from you. How can I change the "Maximum number of > intermediate CAs: unlimited" value. > On Friday, May 22, 2020, 10:57:45 AM GMT+5:30, Nadeera Galagedara < > nadeeragalaged...@yahoo.com> wrote: > > > Dear Dinesh, > > That is a great explanation. That problem that problem is also solved. > Again thank you. > > On Wednesday, May 20, 2020, 08:27:56 PM GMT+5:30, Dinesh Prasanth > Moluguwan Krishnamoorthy wrote: > > > Hi Nadeera, > > I'm glad I could resolve your issues. > > As for the friendly/nickname, these names are customizable based on the > system you use and are not specified during the certificate issuance. > > For instance, when you specified " > *pki_ca_signing_nickname=mycompany_nickname"* this nickname was used to > import the CA system certificate in your PKI server's NSSDB. You can view > this by doing `certutil -L -d /etc/pki/pki-tomcat/alias` and you should see > the *mycompany_nickname* listed. > > I have very limited knowledge of handling certificates in windows. From > Googling around: you can try to *right-click on the certificate -> > Properties -> "general" tab -> Set "Friendly Name"*. > > HTH > > Regards, > --Dinesh > > On Wed, May 20, 2020 at 3:28 AM Nadeera Galagedara < > nadeeragalaged...@yahoo.com> wrote: > > Dear Dinesh, > > Thank you for your support and it is been very helpful. I am using Centos > 7 and the version came with it is 10.5. I am using that version. I think I > have corrected the country (with c=LK). But I still have a problem with the > nickname. > > I used the *pki_ca_signing_nickname=mycompany_nickname* line but still > the friendly name show on windows PC (I have imported the issued > certificate to a windows PC) format like 's ID. > My requirement is to
[Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#733 (master - 2a95153)
Build Update for dogtagpki/pki-nightly-test - Build: #733 Status: Errored Duration: 13 mins and 52 secs Commit: 2a95153 (master) Author: Dinesh Prasanth M K Message: Remove EOL F29 from matrix and add support for v10.8 branch Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/1cec22733aad03cad1e589a08281f4a2db79ec90...2a95153102234446e6beb5d4074ae6eebd760fb3 View the full build log and details: https://travis-ci.org/github/dogtagpki/pki-nightly-test/builds/693449491?utm_medium=notification_source=email -- You can unsubscribe from build emails from the dogtagpki/pki-nightly-test repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=20325727_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
