Hello guys.
I have a certbot and boulder copy running in 2 local VM and I m using Ubuntu server trusty. Everything works fine. However, now im trying to get the certificate after the challenges are completed using curl. So after doing all the challenges and getting a new certificate I do this: curl -i -H "Accept: application/crt" -H "Content-Type: application/json" http://172.17.0.4:4000/acme/cert/ff1ffe82ed...#certId
172.17.0.4:4000 Btw, this is where my Boulder is listening
I was expecting to get the same certificate but I get some cyphered text, I guess it is the certificate, so how can I read that? Or im getting it all wrong and that cant be done?
Thanks in advance!!
GET /acme/cert/asdf HTTP/1.1
Host: example.com
Accept: application/pkix-cert
HTTP/1.1 202 Accepted
Retry-After: 120
The default format of the certificate is DER (application/pkix-cert).
The client may request other formats by including an Accept header in
its request.
The server provides metadata about the certificate in HTTP headers.
In particular, the server MUST include a Link relation header field
[RFC5988] with relation "up" to provide a certificate under which
this certificate was issued, and one with relation "author" to
indicate the registration under which this certicate was issued. The
server MAY also include an Expires header as a hint to the client
about when to renew the certificate. (Of course, the real expiration
of the certificate is controlled by the notAfter time in the
certificate itself.)
You will need to grab the DER and Conver it to PEM.
Thank you all, after @ahaw021 comment I realized that it wasnt base64 encoded so of course I couldnt view the contents. However, I still dont get the .pem certificate after saving it in a file and then using the openssl commandā¦what I get is a malformed der encoded file, so I think I ll have to rethink the curl approach, I ll keep working around it, thank you all guys!
Hello, I m back here with my computer. After seeing the DER file carefully I have realized that the certificate i am getting when doing the curl petition comes from the fake CA and it is not the actual certificate that im trying to get with curl. I guess this is because after Certbot ends, then the certificate isnt available again at the the uri, right?
Commands: curl -i -H "Accept: application/json" -H "Content-Type: application/json" http://172.17.0.4:4000/acme/cert/ff1ffe82edc1c851ca6c6e60ea171e18574c > myDer.cer
I havenāt thought about the other possible part of the problem, but the reason your DER file is corrupt is that you used curl -i. The -i option includes web headers in the output, yet they are not part of the file sent by the web server and hence your output is a āweb transaction that includes a DER fileā rather than āa DER fileā. If you leave off the -i option, you can at least fix the file corruption concern.
You were absolutely right!!! I was modifying the der file myself to remove the headers but it was corrupted anyway, I removed the -i field and it worked perfect so I got the certificate just like I wanted
About the h2ppy h2cker fake CA I first checked if it was because I was passing the -csr myself but removing that field didnāt change the CA. Then I thought that it may just be because I am using my own Boulder copy and doing the challenge to a server that I am running but it is not accessible from the Internet. In fact, all the other certifiactes that I have asked for using the full certbot procedure have the the same CA but the message after the challenge says Congratulations!!
So, am I right or am I f***?
Iām not sure if I understood your most recent question, but if you run your own copy of Boulder, the certificates that it issues are signed by itself, not by Letās Encrypt. Only Letās Encrypt itself can issue publicly-trusted Letās Encrypt certificates. Running your own copy of Boulder is appropriate only for testing purposes, or when you want to create your own internal organizational CA, or when you want to go through the auditing and approval process to become a publicly-trusted CA.