Infisical
Error trying to connect: invalid peer certificate: BadSignature
Trying to migrate from the old SDK to the new SDK (poor communication on Infisical's behalf by the way, customers weren't given a warning ahead of time and half of my website practically went offline).
Unfortunately, the new SDK is giving an error:
dsn = infisical_client.getSecret(options=GetSecretOptions(environment="prod", project_id="<project>", secret_name="<name>")).secret_value
File "/usr/local/lib/python3.10/dist-packages/infisical_client/infisical_client.py", line 42, in getSecret
result = self._run_command(Command(get_secret=options))
File "/usr/local/lib/python3.10/dist-packages/infisical_client/infisical_client.py", line 36, in _run_command
raise Exception(response["errorMessage"])
Exception: error sending request for url (https://app.infisical.com/api/v1/auth/universal-auth/login): error trying to connect: invalid peer certificate: BadSignature
I did look this up and apparently this has happened before in a TypeScript integration problem. Doesn't appear to be something I can solve client-side at face value. I have checked the project ID is correct, the client secret and ID are correct too.
My code:
infisical_client = InfisicalClient(ClientSettings(
client_id="<id>,
client_secret="<secret>",
))
dsn = infisical_client.getSecret(options=GetSecretOptions(environment="prod", project_id="<something>", secret_name="<value>")).secret_value
Exactly what it says on the documentation. Am I just being silly?
I have since closed my account on Infisical and moved to Doppler. I am not going to wait for a fix to bring my website back online, instead I am sticking with a team that is far more robust and communicates more effectively. This change should have come with advanced notice which it did not. I shall leave this open to be fixed, but I do not have the capacity to test nor help with the solution.
We are experiencing the same problem.
That sucks, i'm sorry to hear. Just out of curiosity, were you using the old SDK prior to this?
We are experiencing the same problem.
That sucks, i'm sorry to hear. Just out of curiosity, were you using the old SDK prior to this?
Yes, we were. Trying to migrate to the new one but it has proven to be unfruitful. I'm actively speaking with the founding team now but we haven't been able to make any progress yet.
We are experiencing the same problem.
That sucks, i'm sorry to hear. Just out of curiosity, were you using the old SDK prior to this?
Yes, we were. Trying to migrate to the new one but it has proven to be unfruitful. I'm actively speaking with the founding team now but we haven't been able to make any progress yet.
Did you receive any notice of the deprecation beforehand? I am sad to hear your experience was just as unfruitful as mine, but I am glad to hear at least you are talking to the team - I sent a message over an hour ago and haven't heard a peep so far.
We are experiencing the same problem.
That sucks, i'm sorry to hear. Just out of curiosity, were you using the old SDK prior to this?
Yes, we were. Trying to migrate to the new one but it has proven to be unfruitful. I'm actively speaking with the founding team now but we haven't been able to make any progress yet.
Did you receive any notice of the deprecation beforehand? I am sad to hear your experience was just as unfruitful as mine, but I am glad to hear at least you are talking to the team - I sent a message over an hour ago and haven't heard a peep so far.
Nope, no warning.
We are experiencing the same problem.
That sucks, i'm sorry to hear. Just out of curiosity, were you using the old SDK prior to this?
Yes, we were. Trying to migrate to the new one but it has proven to be unfruitful. I'm actively speaking with the founding team now but we haven't been able to make any progress yet.
Did you receive any notice of the deprecation beforehand? I am sad to hear your experience was just as unfruitful as mine, but I am glad to hear at least you are talking to the team - I sent a message over an hour ago and haven't heard a peep so far.
Nope, no warning.
Ouch. I hope you find a resolution soon, really awful situation to be put in depending on how integrated Infisical is in your stack. I am hoping the disruption isn't too great on your end.
Hi everyone. Infisical recently underwent a migration, and this seems to be related. I'm looking into this on my end. Thank you all for chipping in with details!
I'll let you all know once I have a solution ready!
Hi @ameasere and @andrew-arkhipov,
Foremost, we're sorry for the issues, including this one, caused as a result of the necessary maintenance/migration this past weekend; we'll have more to say about it later this/next week once it has been fully ironed out. As a team, we've worked hard to significantly test out all related features this past few weeks but it was possible that we missed a few given the sheer size of the initiative — For that we're extremely sorry and take full responsibility over any disruption caused.
We care deeply about our customers and the experience of using Infisical; we know that your infrastructure depends on the availability of our own and spent the weekend replying to hundreds of messages, patching any residue left from the maintenance, and communicating with customers across various channels. In general, the maintenance initiative went well considering its scope but admittedly we missed the mark here.
As @DanielHougaard mentioned, we're currently working together with related engineer(s) on the team to promptly address this issue but the nature of our globally distributed team and individual specialization means that there may be delays. That said, we hope to have this issue patched up as soon as possible for anyone experiencing it.
The team and I are personally sorry once again for the unintended result of the maintenance and hope that we can regain your trust overtime; the initiative itself was necessary and we sincerely spent significant effort testing a large surface area of the codebase.
Hi @ameasere and @andrew-arkhipov,
Foremost, we're sorry for the issues, including this one, caused as a result of the necessary maintenance/migration this past weekend; we'll have more to say about it later this/next week once it has been fully ironed out. As a team, we've worked hard to significantly test out all related features this past few weeks but it was possible that we missed a few given the sheer size of the initiative — For that we're extremely sorry and take full responsibility over any disruption caused.
We care deeply about our customers and the experience of using Infisical; we know that your infrastructure depends on the availability of our own and spent the weekend replying to hundreds of messages, patching any residue left from the maintenance, and communicating with customers across various channels. In general, the maintenance initiative went well considering its scope but admittedly we missed the mark here.
As @DanielHougaard mentioned, we're currently working together with related engineer(s) on the team to promptly address this issue but the nature of our globally distributed team and individual specialization means that there may be delays. That said, we hope to have this issue patched up as soon as possible for anyone experiencing it.
The team and I are personally sorry once again for the unintended result of the maintenance and hope that we can regain your trust overtime; the initiative itself was necessary and we sincerely spent significant effort testing a large surface area of the codebase.
While I appreciate the above, I still find major issue with the lack of warning in advance to customers with the Python SDK that the team deprecated. In favour of this one, the prior SDK was deprecated and for some reason or another, the API it used stopped accepting service tokens; instead returning nothing. This prompted a forced migration process which as you duly noted had some growing pains. I can only guess that service tokens were dropped in favour of machine identities since it appeared you cannot create or manage them anymore, the tab was simply replaced with the machine identities option.
While I appreciate the above, I still find major issue with the lack of warning in advance to customers with the Python SDK that the team deprecated. In favour of this one, the prior SDK was deprecated and for some reason or another, the API it used stopped accepting service tokens; instead returning nothing. This prompted a forced migration process which as you duly noted had some growing pains. I can only guess that service tokens were dropped in favour of machine identities since it appeared you cannot create or manage them anymore, the tab was simply replaced with the machine identities option.
Hi @ameasere,
To clarify, the old Python SDK was not yet deprecated, hence there was no deprecation notice for it; both new and old SDKs were meant to work for the time being until further notice.
The issue in this case is more so to do with the maintenance/migration initiative from this past weekend that unfortunately affected the functionality of the old SDK; this was unintended and we’re sorry that this affected your deployment. We’ve since identified and resolved the issue, and the old Python SDK should now be functioning as expected. As for the service token tab, you can still create and delete service tokens in under your Project > Access Control > Service Tokens; it was moved from Project > Settings around 1.5 months ago.
Finally, we’re still investigating and working to replicate this peer certificate issue associated with the new Python SDK and will keep this thread updated as we get to the resolution.
While I appreciate the above, I still find major issue with the lack of warning in advance to customers with the Python SDK that the team deprecated. In favour of this one, the prior SDK was deprecated and for some reason or another, the API it used stopped accepting service tokens; instead returning nothing. This prompted a forced migration process which as you duly noted had some growing pains. I can only guess that service tokens were dropped in favour of machine identities since it appeared you cannot create or manage them anymore, the tab was simply replaced with the machine identities option.
Hi @ameasere,
To clarify, the old Python SDK was not yet deprecated, hence there was no deprecation notice for it; both new and old SDKs were meant to work for the time being until further notice.
The issue in this case is more so to do with the maintenance/migration initiative from this past weekend that unfortunately affected the functionality of the old SDK; this was unintended and we’re sorry that this affected your deployment. We’ve since identified and resolved the issue, and the old Python SDK should now be functioning as expected. As for the service token tab, you can still create and delete service tokens in under your Project > Access Control > Service Tokens; it was moved from Project > Settings around 1.5 months ago.
Finally, we’re still investigating and working to replicate this peer certificate issue associated with the new Python SDK and will keep this thread updated as we get to the resolution.
The repository literally says it is deprecated - when the repository says it is deprecated, it means deprecated; if it was intended to be "they both work for now", then that isn't deprecation, rather a planned deprecation. Again, that still should come with notice to customers using it to prepare them for potential migration.
I did exactly what you said for creating a service token using those same steps you identified, the SDK refused it and said the token is in an incorrect format. I tried upgrading the SDK version, nothing helped.
I totally understand your frustrations. Our intentions were to keep the old Python SDK working both before and after the migration, whilst slowly moving users to the newer SDK & Machine Identities. With that said, we had some unforeseen challenges associated with the maintenance, which impacted both the new and old SDK's.
We've just pushed an update that makes all older versions of the old Python SDK work like they used to. Again, we're terribly sorry, and we're now taking steps to ensure something like this can never take place again.
Could I please ask you to try the 2.1.8 version? Thanks!
Somebody else may have to, I have already deleted my Infisical account, sorry.
Any update on this issue? The same problem persisted even after trying with the "2.1.8 version".
Resolved. If anyone is looking. From @ChatGPT:
The error you're encountering suggests that the Infisical SDK running in your Docker container is having issues with TLS certificate verification. Specifically, it appears that the Rust-based TLS client (rustls) is unable to find and verify the Certificate Authority (CA) certificates on your system. This results in an "UnknownIssuer" error when trying to establish a secure connection.
Here's a step-by-step approach to resolving this issue:
-
Install CA Certificates in the Docker Container: Ensure that the CA certificates are installed in your Docker container. Most Linux distributions provide a package for CA certificates. For example, on Debian-based distributions, you can install them using the following command:
FROM node:14 # Install CA certificates RUN apt-get update && apt-get install -y ca-certificates # Add your application code here COPY . /app WORKDIR /app # Install dependencies RUN npm install # Start the application CMD ["node", "your-app.js"] -
Configure Node.js to Use System CA Certificates: Sometimes Node.js does not use the system's CA certificates by default. You can configure Node.js to use them by setting the
NODE_EXTRA_CA_CERTSenvironment variable.FROM node:14 # Install CA certificates RUN apt-get update && apt-get install -y ca-certificates # Add your application code here COPY . /app WORKDIR /app # Install dependencies RUN npm install # Set the environment variable for CA certificates ENV NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt # Start the application CMD ["node", "your-app.js"] -
Ensure Correct DNS Configuration: Make sure that the DNS settings in your Docker container are correct and that it can resolve the hostname properly. You can add a custom DNS server if necessary.
FROM node:14 # Install CA certificates RUN apt-get update && apt-get install -y ca-certificates # Add your application code here COPY . /app WORKDIR /app # Install dependencies RUN npm install # Set the environment variable for CA certificates ENV NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt # Add custom DNS server if necessary RUN echo "nameserver 8.8.8.8" > /etc/resolv.conf # Start the application CMD ["node", "your-app.js"] -
Verify the Certificates Manually: If the problem persists, you might want to verify that the CA certificates are indeed present in the specified path (
/etc/ssl/certs/ca-certificates.crt). You can do this by running a bash shell in the Docker container and checking the file.docker run -it --rm your-docker-image /bin/bash cat /etc/ssl/certs/ca-certificates.crt
By following these steps, you should be able to resolve the TLS certificate verification issue in your Docker container. If the problem persists, you may need to further investigate the network configuration or the specific CA certificates required by the Infisical SDK.