Describe the problem/error/question
We get the error “error:0909006C:PEM routines:get_name:no start line” in the docker Version 0.230.3 of n8n. With older Versions of n8n (primarily Desktop Version) we can connect to the same rabbit MQ without this issue.
What is the error message (if any)?
“error:0909006C:PEM routines:get_name:no start line”
Information on your n8n setup
- n8n version:0.230.3
- Database :sqlite
Running n8n via Docker
- Operating system: Linux
- has there been any changes in the latest docker versions regarding SSL behaviour?
- What we see is that we cannot input the PEM Data in Text as it used to be. So we cannot see if the input field takes the “CRLF” from the PEM Data into account. We just see the “Dots” after copying the PEM Data into the field. How can we check wheter the PEM Data is correctly saved?
Our Format seems to be correct and with n8n Desktop Versions 1.6 and 1.7 it works perfectly. With n8n Desktop 0.209.4 and Docker Version 0.230.3 we have the issues with this PEM routines…
Hi @Mike2022, I am so sorry for the trouble. It seems like this could be related to the functionality hiding certain secret values in the UI, which seems to struggle with some multi-line values.
From taking a look it seems @mieky stumbled across this behaviour as well and has already added this to our bug tracker for a fix. We will of course let you know once this is resolved.
As a workaround in the meantime, can you try adding your keys and certificates as expressions rather than as plain text?
Thanks for the very fast response.
We tried that already, but somehow it does not work. How do have to add the text in some special format?
You shouldn’t have to. One thing to note is that the credential check might fail (with a “Couldn’t connect with these settings” message), but the node still seems to work as it should.
Can you try ignoring the message in the credentials screen and check whether the node itself works for you?
The connection itself seems to work now. As you mentioned, we ignored the error from the connection test but we get an access refused error from the rabbit mq. From another rabbit mq client it worked with the same credentials. First we are now trying to investigate the issue from the rabbit mq side.
Thx for the update Michael and sorry for the trouble this bug has caused!
We got the feedback from the rabbit mq guys, that we try to declare the queue but the queue is already declared and our user has no rights to declare the queue. So we should not try to declare the queue an only try to “connect”.
We get the following error from rabbit:
2023-06-15 08:45:41.612330+00:00 [info] <0.7795.2> connection <0.7795.2> (IP-Adress:36434 → IP-Adress:5671): user ‘Username’ authenticated and granted access to vhost ‘vhost name’
2023-06-15 08:45:41.661732+00:00 [error] <0.7813.2> Channel error on connection <0.7795.2> (IP-Adress:36434 → IP-Adress:5671, vhost: ‘vhost name’, user: ‘Username’), channel 1:
2023-06-15 08:45:41.661732+00:00 [error] <0.7813.2> operation queue.declare caused a channel exception access_refused: access to queue ‘queue name’ in vhost ‘vhost name’ refused for user ‘Username’
2023-06-15 08:45:41.681687+00:00 [warning] <0.7795.2> closing AMQP connection <0.7795.2> (IP-Adress:36434 → IP-Adress:5671, vhost: ‘vhost name’, user: ‘user name’):
Do you know if we can set somwhere in the trigger to not declare the queue and only connect?
I don’t know wheter this is possible, but thats the feedback we have so far from the rabbit admin…
Hi @Mike2022, to be honest I am not overly familiar with RabbitMQ, so am not quite sure about this one. @agobrecht I see you’ve worked on the RabbitMQ node recently, do you know if there’s a way to prevent the node from declaring the queue?
I am not sure if it is possible using the current library that we are using.
Is this somehow testable?
@Mike2022 anything is testable but if the library doesn’t support it then it will make things a bit trickier and will take more time to work out.
Are there any news? We would need to know if your library supports this or not? If not we have to check with the Admins if we can change the access rights.
Maybe a newbie question: If we would like to raise a feature request to support having manageable access rights on the rabbit mq node, how can we do that?
Thanks a lot!
It is probably going to take a while for us to dig into the package we use to see if it is possible, I suspect it is possible so it would then just be down to development time, testing and reviewing which can take up to a couple of weeks depending on the priority.
It would be worth speaking to your admin to see if they can change the access rights as I suspect that will be a bit quicker than waiting for a new feature to be implemented.
You can open a new topic and select the feature request option if you wanted to raise a request and we will typically use that to work out how popular an idea is with the community.
@Mike2022 did you find a way to make it works?
I’m facing the exact same problem on v0.228.3
Either on credentials screens or either running the node I get :
ERROR: error:0480006C:PEM routines::no start line
The code error is different to yours.
Somtimes, it looks like the error dissapear, but the rabbitmq trigger or node is loading infinitly…
Any idea how can we make it works @Jon ?
Thanks in advance for your help
Tis message can appear out off different reasons.
Did you enter all certificates the correct way?
If yes, I would suggest to check the access rights on the rabbit side. If you cannot daclare a queue with your rights, the Rabbit Admin needs to grant you access to declare a queue.
In our case that is the temporary solution. I now will raise a change request for n8n to support different access right levels.
For security reason, my RabbitMQ instance must be accessed throught a SSH tunnel. SSL certificates won’t help to make the connection properly.
How can we deal with that constraint ?
Hi @Locos, n8n does not currently offer SSH tunneling itself when connecting to RabbitMQ I am afraid.
So I think you would have to open the SSH tunnel on the machine you’re running n8n on.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.