pkisharp / acmesharpcore Goto Github PK

Per the docs, order should be in Ready state before finalization.
See https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.1.3

The code in AcmeHostedServices checks for PendingState, not readystate.

if (AcmeState.PendingStatus == _state.Order.Payload.Status)
{
_logger.LogInformation("Generating CSR");

When I execute this code I get the following errors on await _client.GetNonceAsync(). Am I missing something?

Error:

System.Private.CoreLib: Exception while executing function: RenewCertificates. System.Private.Uri: Value cannot be null.
Parameter name: uriString.

// initialize client
var acmeApiUrl = new Uri("https://acme-staging-v02.api.letsencrypt.org/");
var acme = new AcmeProtocolClient(acmeApiUrl );

// verify directory.NewNonce exists
var directory = await _client.GetDirectoryAsync();
Console.WriteLine(directory.NewNonce); // https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce

// get nonce, used to communicate w/ server
await _client.GetNonceAsync();

// make request to create account
var contactEmails = new string[] { "mailto:[email protected]" };
var account = await _client.CreateAccountAsync(contactEmails, termsOfServiceAgreed: true);
var accountKey = new WinmarkAccountKey {
    KeyType = _client.Signer.JwsAlg,
    KeyExport = _client.Signer.Export()
};

// store account details
Console.WriteLine(account);
Console.WriteLine(accountKey);
_client.Account = account;

First, thanks for this port to ACME v2! I ran into a minor issue when experimenting with the CLI reference implementation. If I choose to use RSA, rather than the default ES, algorithm, the JwsAlg is properly stored as RS256 (hashSize=256, keySize=2048). However, when the state information is restored, in ../src/Examples/ACMECLI/Program.cs:

                // ...
176:            if (LoadStateInto(ref accountKey, failThrow: false,
177:                    Constants.AcmeAccountKeyFile))
178:            {
179:                accountSigner = accountKey.GenerateTool();
                    // ...
186:            }

The current implementation of GenerateTool() resets tool.KeySize, rather than tool.HashSize when RS-style, vs ES-style keytypes are used. I made this change to correct this locally:

$ git diff ExamplesAccountKey.cs
diff --git a/src/examples/Examples.Common.PKI/ExamplesAccountKey.cs b/src/examples/Examples.Common.PKI/ExamplesAccountKey.cs
index 989bd3e..7b12c3e 100644
--- a/src/examples/Examples.Common.PKI/ExamplesAccountKey.cs
+++ b/src/examples/Examples.Common.PKI/ExamplesAccountKey.cs
@@ -24,7 +24,7 @@ namespace Examples.Common.PKI
             if (KeyType.StartsWith("RS"))
             {
                 var tool = new ACMESharp.Crypto.JOSE.Impl.RSJwsTool();
-                tool.KeySize = int.Parse(KeyType.Substring(2));
+                tool.HashSize = int.Parse(KeyType.Substring(2));
                 tool.Init();
                 tool.Import(KeyExport);
                 return tool;

I believe the above is the intended behavior. I'll submit a PR with this simple change for you to review and merge if it is acceptable. (See: #32)

After 2 years of work with no issues GetAuthorizationDetailsAsync started giving an error:

https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/83121408

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Method not allowed",
  "status": 405
}

In AcmeProtocolClient, we can clearly see that code to handle validity period has been commented out ~2 years ago.
I could not find an explanation for this in commit history.

However, I would like to use this library with a different CA with our own variable validity periods.
I was wondering if there are any plans to make this functional?

First of all I want to thank you for all the effort put into ACMESharpCore so far, the code feels very clean and I haven't run into any issues testing it with WACS 2.0.

As far as I can tell the only thing that we're really missing is certificate revocation, so I'd hereby like to open an issue to track that.

Hello, could you please suggest or provide a code snippet, how to export domain TLS private key used for certificate(s) generation, from console client ACMECLI?
For example, following this guide, it's a file domain.key , generated by command openssl genrsa 4096 > domain.key and used for command

openssl req -new -sha256 -key domain.key -subj "/" \
-reqexts SAN -config <(cat /etc/ssl/openssl.cnf \
<(printf "\n[SAN]\nsubjectAltName=DNS:foo.com,DNS:www.foo.com")) 

I've added some automation for ACMECLI (automatically passing file challenges by using FTP access to website/domain. If you want/need, I can create a pull request for that feature, it's really useful) and it works pretty fine, obtained certificate is good and valid, but FXDomains.com also requires a private key to install certificate.

So, for now I need to get it somehow in the text (not binary) form, could you help?

P.S. I'm very sorry, I definitely not a computer security & certificates expert so this area is pretty new for me.

We had one user that seemed to get the wrong tokens whatever they tried to validate. @webprofusion-chrisc pointed out that there may be very sneaky bugs regarding the serialization of some EC keys: win-acme/win-acme#1001 (comment).

Then I looked into the ACMESharpCore code and found this comment in ESJswTool.cs, line 83

// TODO: this is inefficient and corner cases exist that will break this -- FIX THIS!!!

Somehow this users problem disappeared after he installed ASP.NET on the machine, but I'm worried it might come back and bite us in the face.

Hey, I am very interested in utilizing and potentially contributing to ACMESharp and ACMESharpCore. I noticed that there doesn't seem to be a notion of the Vault in Core. Was this interface removed? If so - are there any plans to port the Vault over? How should we be handling state now?

I'm experiencing a weird issue where in the example app, GetAsync(order.Payload.Certificate) will give me a PEM containing both the domain cert and the intermediate cert. However, in my real app, where I consume the ACMESharp nuget package, the PEM does not contain the intermediate cert. I might be missing something, but it seems really weird.

Does the payload from the ACME API contain both certs, or is there some special work being done inside ACMESharp in this area?

If the option --export-pfx [filename] is ran as shown in these instructions with the following command example, the private key is not added to the export:

acmecli --dns myapp.example.com --dns myapp-0.example.com --dns myapp-1.example.com --export-pfx mycertificate.pfx

This can be verified by running the example code in debug mode, and investigating the cert object currently being created on line 539. The property HasPrivateKey will be false. This can also be verified by checking the certificate after export. It does not contain the private key. This is the code block referenced around line 539, with an additional comment:

if (ExportPfx != null)
{
    Console.WriteLine("Exporting Certificate as PKCS12...");
    using (var cert = new X509Certificate2(LoadRaw<byte[]>(true, Constants.AcmeOrderCertFmt, orderId)))
    {
        // cert.HasPrivateKey is false!
        await File.WriteAllBytesAsync(ExportPfx, cert.Export(X509ContentType.Pkcs12));
    }
}

I know it's old now, but we're stilling maintaining an old Azure Cloud Services project that we're converting over to use Windows Containers (can't move to .NET Core for this project), and a working example of integrating this with OWIN would be ace! ...anyone tried?

I was going through the code and saw that the AcmeProtocolClient's CreateOrderAsync does not allow the passing of generic identifiers, instead only explicitly supporting dns names. Exposing a list of Identifier could allow the client more flexibility, as in implementing draft specs for IP identifiers: https://tools.ietf.org/html/draft-ietf-acme-ip-05.

Would it be easily implementable in the project's current state? Do it just require a change in method signature/overload?

I need to generate a wildcard certificate (*.domain.com). I'm looking to the code in your AcmeWildcardNameOrderTests class as an example.

It's unclear to me, however, on how exactly to proceed.

For example, in your first test, Test_Create_Order_ForWildDns(), you're starting off with a call to SetTestContext(), which jumps through quite a few hoops to do its work. The complexities only increase from there.

Does this mean that I'll need to replicate all of that in my own code? Is the context required for basic functionality?

Do you have a simple and concise example showing how to use ACMESharpCore to request a wildcard certificate?

PS C:\Windows\system32> Install-Package ACMESharpCore

The package(s) come(s) from a package source that is not marked as trusted.
Are you sure you want to install software from 'NuGet'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): A
Install-Package : Dependency loop detected for package 'ACMESharpCore'.
At line:1 char:1

• Install-Package ACMESharpCore

•   + CategoryInfo          : Deadlock detected: (ACMESharpCore:String) [Install-Package], Exception
    + FullyQualifiedErrorId : DependencyLoopDetected,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
  

Does this client support Pre-Authorization as described in https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.4.1?

Hi,

Please could you confirm if this project is actively maintained still?

I don't see any active issues outstanding but the latest commit was some time ago.

Thanks!

:)

the examples in demo are more complicated

I was working on a project and found that the ability to load a PkiCertificate via an X509Certificate2 instance is missing in PKISharp.SimplePKI 1.0.1.105 package . This method is used in the CLI sample to load the public cert and export with the private key to PFX here

It looks like once that method was added in October 2019, the package was never published with the change. Not sure if there have been other changes missed.

Hi, first of all, thanks for this library, it's a huge timesaver.
I did a peak at the Tests, and found the CLI version quite good.
In it there's a comment that states ExportKey has not enough support in .Net Core/Standard.
I found it out when trying to do a RSA.FromXmlString, it throws a PlatformNotSupported exception.
Any chance here to somehow convert / reconstruct the 6-CertKey file from JSON to a PEM (?) or something 'edible' for OpenSSL to do the pfx conversion as a workaround?

Let's Encrypt will switch to ISRG Root CA starting September 29, 2020.

However, due to the lack of support on some Android devices, the current IdenTrust Root CA is also provided with an alternate HTTP header.

Ref

• https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html
• certbot/certbot#6971
• certbot/certbot#8080

I'm running into an ArgumentException when calling CreateAccountAsync on the Buypass ACMEv2 endpoint (@ https://api.test4.buypass.no/acme-v02/). Seems to be an issue with a regex that gets triggered because they're doing something different than Let's Encrypt, but I haven't been able to look at the decoded JSON get to see what.

System.ArgumentException: 'Invalid Link header format Parameter name: value'

According to msft docs, here https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.2

ConfigureKestrel with listenoptions needs to be called to load cert. I do not see it implemented anywhere:

As in example:
`public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup()
.ConfigureKestrel((context, options) =>
{
options.ListenAnyIP(5005, listenOptions =>
{
listenOptions.UseHttps(httpsOptions =>
{
var localhostCert = CertificateLoader.LoadFromStoreCert(
"localhost", "My", StoreLocation.CurrentUser,
allowInvalid: true);
var exampleCert = CertificateLoader.LoadFromStoreCert(
"example.com", "My", StoreLocation.CurrentUser,
allowInvalid: true);
var subExampleCert = CertificateLoader.LoadFromStoreCert(
"sub.example.com", "My", StoreLocation.CurrentUser,
allowInvalid: true);
var certs = new Dictionary<string, X509Certificate2>(
StringComparer.OrdinalIgnoreCase);
certs["localhost"] = localhostCert;
certs["example.com"] = exampleCert;
certs["sub.example.com"] = subExampleCert;

                httpsOptions.ServerCertificateSelector = (connectionContext, name) =>
                {
                    if (name != null && certs.TryGetValue(name, out var cert))
                    {
                        return cert;
                    }

                    return exampleCert;
                };
            });
        });
    });`

Hi,

I tried to generate a new certificate using the library.
The generation in itself works well, but I couldn't find a way to fetch the full certificate chain associated with the certificate, and this behaviour is causing diverse trusting problems.

Is there a possibility to get this certificate chain ?

Thanks.

EDIT: Seems that the certificate chain is passed in the completed order.
https://community.letsencrypt.org/t/generated-certificate-is-not-trusted/139559/3

We seem to hit a problem when trying the BuyPass endpoint at https://api.test4.buypass.no/acme-v02/. The library tries to find the directory under https://api.test4.buypass.no/directory instead of https://api.test4.buypass.no/acme-v02/directory

Because it's under a folder /acme-v02/ rather than at the root of the website, I think we are running into this problem: https://stackoverflow.com/questions/23438416/why-is-httpclient-baseaddress-not-working

You must place a slash at the end of the BaseAddress, and you must not place a slash at the beginning of your relative URI, as in the following example.

In https://github.com/PKISharp/ACMESharpCore/blob/883d8c683d44409a37a834484e635bde86a28435/src/ACMESharp/Protocol/Resources/ServiceDirectory.cs we can see the Directory url hardcoded to "/directory". It think that should be "directory" and the HttpClient should make it relative to the BaseAddress.

Since Acme has now released as RFC8555, this Client should be updated to remove the usages of GET-Requests where the POST-AS-GET Style Request should be used. Note that I can implement (and am in fact doing so in my local copy of the repo), but I will not be updating the Unittests or the Mockserver. The reason for this is that while I am relatively fluent in the protocol itself, C# is not actually my main language. My use-case for this library is testing my own implementation of the server-side of ACME.

So I guess I'm asking for whether there's interest for my changes to be merged here.

I think the availability of ACMESharpCore would be a good Point to also move to PowershellStandard.

I was Looking into the ACME.POSH last week and started using it more or less successfully.
I'd like to contribute some changes, which would make the Cmdlets more "normalized" - but I have to admit, that would be Breaking changes.

What I mean by normalized:
The Get-ACMEIdentifier Cmdlet for example returns different types for Get-ACMEIdentifier or Get-ACMEIdentifier -IdenRef xxx.
Also Get Outputs should be pipe-able into update Methods and such.

Since I'm not the guy to only complain About that things, I'd happily provide my time to contribute.

Any ideas what could be causing this?

Hi,

Will this work with Azure App Services - Windows, Linux and Docker instances?

For example, pushing the downloaded files to blob storage instead of the local disk, so when new instances start, they can read from the same destination?

I've managed to get a certificate from staging. But if I try to create a new order (with the same DNS names) it still returns the old certificate? Is this by design? If so, when is the earliest I can renew to get a new certificate?

public enum ProblemType is missing enum for orderNotReady

Here is exception we get
Error: System.ArgumentException: Requested value 'orderNotReady' was not found.
at System.Enum.TryParseEnum(Type enumType, String value, Boolean ignoreCase, EnumResult& parseResult)
at System.Enum.Parse(Type enumType, String value, Boolean ignoreCase)
at ACMESharp.Protocol.AcmeProtocolException.Init(Problem problem)
at ACMESharp.Protocol.AcmeProtocolException..ctor(String message, Problem problem)
at ACMESharp.Protocol.AcmeProtocolClient.DecodeResponseErrorAsync(HttpResponseMessage resp, String message, String opName)
at ACMESharp.Protocol.AcmeProtocolClient.SendAcmeAsync(Uri uri, HttpMethod method, Object message, HttpStatusCode[] expectedStatuses, Boolean skipNonce, Boolean skipSigning, Boolean includePublicKey, CancellationToken cancel, String opName)
at ACMESharp.Protocol.AcmeProtocolClient.FinalizeOrderAsync(String orderFinalizeUrl, Byte[] derEncodedCsr, CancellationToken cancel)

If you need any help, add an issue I can pick up.

Hi!

Could you change JwsHelper.cs, line 94 formatting argument of SerializeObject to Formatting.None?

return JsonConvert.SerializeObject(jwsFlatJS, Formatting.None);

It is set to Formatting.Indented now, it causes serializer to generate \r\n while running on Windows. And that leads to "bad request" response from ZeroSSL to literally any signed request.

Works ok on Mac/Linux, likely ZeroSSL can parse either \r or \n, but not both.

Thanks.

The current set of integration tests for Orders and dns-01 Challenges can take a potentially long time to validate either the existence or lack thereof a test record in the DNS system.

The code for this DNS testing does a normal DNS look up which goes through local system's DNS resolver and can be impacted by various caching points but ultimately it can have a wide range of wait times.

For example in the Windows tests the wait for deleted records takes as much as 4.5 minutes (search for _IsDeleted_) and over 1 minute for testing for the existence of newly created records (search for _Exists_).

However in the same set of tests on Linux the same corresponding tests take can take as little as 10 seconds.

In order to provider more consistent and predictable behavior and speed up the execution of the tests in general, it would be useful to improve DNS lookups to resolve the DNS provider specific to the test record domain and then query the provider's DNS servers directly, i.e. resolve the DNS NS records for the target root domain.

I think the JwsTool could need some refactoring.

There should be a proper JwsTool::Create, to create the matching Signer.
I'll submit a proposal, if you agree. That'll also make it easily usable for PS-Core scenarios.