https://ci.debian.net/packages/f/freerdp3/testing/amd64/71709881/

...
 91s autopkgtest [05:23:43]: test connect: [-----------------------
 91s + sudo systemctl start xrdp
 91s + sed -n /^port=[0123456789]/{s/port=//p;q;} /etc/xrdp/xrdp.ini
 91s + port=3389
 91s + test ! isNaturalNumber 3389
 91s /tmp/autopkgtest-lxc.sxxhrfa5/downtmp/build.9KP/src/debian/tests/connect: 13: test: isNaturalNumber: unexpected operator
 91s + timeout 2s xvfb-run -l xfreerdp /v:localhost:3389 /p: /u: /d: /cert:tofu
 91s [05:23:43:223] [5167:0000142f] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Using /p is insecure
 91s [05:23:43:223] [5167:0000142f] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Passing credentials or secrets via command line might expose these in the process list
 91s [05:23:43:223] [5167:0000142f] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Consider using one of the following (more secure) alternatives:
 91s [05:23:43:223] [5167:0000142f] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]:   - /args-from: pipe in arguments from stdin, file, file descriptor or environment variable
 91s [05:23:43:223] [5167:0000142f] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]:   - /from-stdin pass the credential via stdin
 91s [05:23:43:223] [5167:0000142f] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]:   - set environment variable FREERDP_ASKPASS to have a gui tool query for credentials
 91s [05:23:43:230] [5167:00001431] [WARN][com.freerdp.client.x11] - [load_map_from_xkbfile]:     : keycode: 0x08 -> no RDP scancode found
 91s [05:23:43:230] [5167:00001431] [WARN][com.freerdp.client.x11] - [load_map_from_xkbfile]: ZEHA: keycode: 0x5d -> no RDP scancode found
 91s [05:23:43:243] [5167:00001431] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55622e2f84d0]: *************************************************
 91s [05:23:43:243] [5167:00001431] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55622e2f84d0]: This build is using [experimental] build options:
 91s [05:23:43:243] [5167:00001431] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55622e2f84d0]: * 'WITH_VAAPI_H264_ENCODING=ON'
 91s [05:23:43:243] [5167:00001431] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55622e2f84d0]: *
 91s [05:23:43:243] [5167:00001431] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55622e2f84d0]: [experimental] build options might crash the application
 91s [05:23:43:243] [5167:00001431] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55622e2f84d0]: *************************************************
 91s [05:23:43:252] [5167:00001431] [ERROR][com.freerdp.core] - [rdp_set_error_info]: ERRINFO_LOGOFF_BY_USER [0x0001000C]
 91s [05:23:43:252] [5167:00001431] [WARN][com.freerdp.core.rdp] - [rdp_handle_message_channel][0x55622e2f84d0]: MCS message channel id == 0
 91s [05:23:43:252] [5167:00001431] [WARN][com.freerdp.core.rdp] - [rdp_handle_message_channel][0x55622e2f84d0]: MCS message channel id == 0
 91s [05:23:43:252] [5167:00001431] [ERROR][com.freerdp.core.rdp] - [rdp_recv_callback_int][0x55622e2f84d0]: CONNECTION_STATE_LICENSING status STATE_RUN_FAILED [-1]
 91s [05:23:43:252] [5167:00001431] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
 91s [05:23:43:252] [5167:00001431] [INFO][com.freerdp.core] - [rdp_print_errinfo]: ERRINFO_LOGOFF_BY_USER (0x0000000C):The disconnection was initiated by the user logging off their session on the server.
 91s Xfreerdp exited before the timeout, it has likely
 91s failed to connect. The test has therefore failed.
 91s + test 131 != 124
 91s + printf %s\n Xfreerdp exited before the timeout, it has likely  failed to connect. The test has therefore failed.
 91s + exit 2
 91s autopkgtest [05:23:43]: test connect: -----------------------]
...




For reference, a non-failing test with xrdp 0.10.5:

...
 61s autopkgtest [01:23:28]: test connect: [-----------------------
 62s + sudo systemctl start xrdp
 62s + sed -n /^port=[0123456789]/{s/port=//p;q;} /etc/xrdp/xrdp.ini
 62s + port=3389
 62s + test ! isNaturalNumber 3389
 62s /tmp/autopkgtest-lxc.ryr9024k/downtmp/build.3ct/src/debian/tests/connect: 13: test: isNaturalNumber: unexpected operator
 62s + timeout 2s xvfb-run -l xfreerdp /v:localhost:3389 /p: /u: /d: /cert:tofu
 62s [01:23:29:422] [5534:0000159e] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Using /p is insecure
 62s [01:23:29:422] [5534:0000159e] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Passing credentials or secrets via command line might expose these in the process list
 62s [01:23:29:422] [5534:0000159e] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Consider using one of the following (more secure) alternatives:
 62s [01:23:29:422] [5534:0000159e] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]:   - /args-from: pipe in arguments from stdin, file, file descriptor or environment variable
 62s [01:23:29:422] [5534:0000159e] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]:   - /from-stdin pass the credential via stdin
 62s [01:23:29:422] [5534:0000159e] [WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]:   - set environment variable FREERDP_ASKPASS to have a gui tool query for credentials
 62s [01:23:29:428] [5534:000015a0] [WARN][com.freerdp.client.x11] - [load_map_from_xkbfile]:     : keycode: 0x08 -> no RDP scancode found
 62s [01:23:29:428] [5534:000015a0] [WARN][com.freerdp.client.x11] - [load_map_from_xkbfile]: ZEHA: keycode: 0x5d -> no RDP scancode found
 62s [01:23:29:448] [5534:000015a0] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55f32cc0e4d0]: *************************************************
 62s [01:23:29:448] [5534:000015a0] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55f32cc0e4d0]: This build is using [experimental] build options:
 62s [01:23:29:448] [5534:000015a0] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55f32cc0e4d0]: * 'WITH_VAAPI_H264_ENCODING=ON'
 62s [01:23:29:448] [5534:000015a0] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55f32cc0e4d0]: *
 62s [01:23:29:448] [5534:000015a0] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55f32cc0e4d0]: [experimental] build options might crash the application
 62s [01:23:29:448] [5534:000015a0] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x55f32cc0e4d0]: *************************************************
 62s fuse: device /dev/fuse not found. Kernel module not loaded?
 64s [01:23:31:291] [5534:0000159e] [ERROR][com.freerdp.utils.signal] - [fsig_term_handler]: Caught signal 'Terminated' [15]
 64s + test 124 != 124
 64s [01:23:31:295] [5534:0000159e] [ERROR][com.freerdp.core] - [freerdp_abort_connect_context]: ERRCONNECT_CONNECT_CANCELLED [0x0002000B]
 64s [01:23:31:301] [5534:000015a0] [WARN][com.freerdp.client.common.cliprdr.file] - [cliprdr_file_session_terminate]: winpr_PathFileExists(/tmp/com.freerdp.client.cliprdr.5534) failed
 64s X connection to :99 broken (explicit kill or server shutdown).
 64s [01:23:29:463] [5534:000015a0] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format  PIXEL_FORMAT_BGRX32
 64s [01:23:29:463] [5534:000015a0] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_BGRA32
 64s [01:23:29:468] [5534:000015a0] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded fake backend for rdpsnd
 64s [01:23:29:468] [5534:000015a0] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel ainput
 64s [01:23:29:468] [5534:000015a0] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpgfx
 64s [01:23:29:468] [5534:000015a0] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel disp
 64s [01:23:29:468] [5534:000015a0] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpsnd
 64s [01:23:31:295] [5534:0000159e] [INFO][com.freerdp.core] - [sig_abort_connect]: Signal Terminated [15], terminating session 0x55f32cc0e4d0
 64s [01:23:31:295] [5534:000015a0] [INFO][com.freerdp.client.common] - [client_auto_reconnect_ex]: Network disconnect!
 64s /tmp/autopkgtest-lxc.ryr9024k/downtmp/wrapper.sh: Killing leaked background processes: 5534
 64s     PID TTY      STAT   TIME COMMAND
 64s /tmp/autopkgtest-lxc.ryr9024k/downtmp/wrapper.sh: 246: kill: No such process
 64s
 64s /tmp/autopkgtest-lxc.ryr9024k/downtmp/wrapper.sh: 248: kill: No such process
 64s
 64s autopkgtest [01:23:31]: test connect: -----------------------]
 ...

Is this fixed in new (not yet packaged) version 3.27.1? More specifically
maybe with this https://github.com/FreeRDP/FreeRDP/pull/12898

Karolis M.

We believe that the bug you reported is fixed in the latest version of
freerdp3, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1138658@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated freerdp3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 30 Jun 2026 09:34:23 +0300
Source: freerdp3
Architecture: source
Version: 3.27.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Remote Maintainers <debian-remote@lists.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Closes: 1138658 1140689
Changes:
 freerdp3 (3.27.1+dfsg-1) unstable; urgency=medium
 .
   [ Jeremy Bícha ]
   * Don't build sso-mib feature on i386
 .
   [ Grayson Wolf ]
   * fix test failures by enforcing TLS security
 .
   [ Michael Tokarev ]
   * Revert "Don't build sso-mib feature on i386"
   * stop disabling PKCS11 on ubuntu (Closes: #1140689)
   * new upstream bugfix release 3.27.1
     Hopefully closes: #1138658 (xrdp debci failure)
Checksums-Sha1:
 5812bdd93c7dbc2c0cb9e6195fa7ccb85db35022 4559 freerdp3_3.27.1+dfsg-1.dsc
 4962c7a87db1b604ee247a667c1a840ad26454ab 5196608 freerdp3_3.27.1+dfsg.orig.tar.xz
 c81bbf63015131647c948d2f7a36c15c0fc1a6ba 55476 freerdp3_3.27.1+dfsg-1.debian.tar.xz
 c1e6ea64bc8593257bb5cc9722a6efcdd5fa9765 6089 freerdp3_3.27.1+dfsg-1_source.buildinfo
Checksums-Sha256:
 832188c5f6781ef3a76f2acaa58e0da099ade30a045bffd89b17928d14f57369 4559 freerdp3_3.27.1+dfsg-1.dsc
 7283c75b0b2c254ad3895cc8c419c10273dfb6a71dbb15cdd971747468018ae8 5196608 freerdp3_3.27.1+dfsg.orig.tar.xz
 8b743b57f77672d136df6b043f8ddcae9589bce81e12ded070c2697e9afb3698 55476 freerdp3_3.27.1+dfsg-1.debian.tar.xz
 1b3142ddde38cd162fed9adbbd921e7aef7d2ece1ad87418bab0d926c10d7e44 6089 freerdp3_3.27.1+dfsg-1_source.buildinfo
Files:
 2be3ccaff7fc412be0fb82e2f68931a5 4559 x11 optional freerdp3_3.27.1+dfsg-1.dsc
 73647621df4f691c5d776ea5689e426d 5196608 x11 optional freerdp3_3.27.1+dfsg.orig.tar.xz
 70aa1ca284f6bf4ab27aba023b8b15ff 55476 x11 optional freerdp3_3.27.1+dfsg-1.debian.tar.xz
 85ae95c99d98a2d16c66636d4afdf309 6089 x11 optional freerdp3_3.27.1+dfsg-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

wsG7BAEBCgBvBYJqQ2OHCRCCqkokOx6UeEcUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmcu5vdANLRi4a6vo0BIbSbuJ1pX20YEAgg6UT8QDOfZ
HBYhBGSqKrUx1WkDNmv++YKqSiQ7HpR4AAD56BAAqy8q5o0oD4mp3hvlAEXVZHWu
0jBSEzURIX2j1im4EdZy2lnpXhDfR70bHXKNeaY73vcyXhxc9m8O95rZVl4HjHaA
rm2o7aX49qQnfZZIffSOrKzuxst4bwUIoe3n7Klj+4oJEhbkC12Df3Hn/YS9Tc0s
ws/pqmu40Rx6CpScNUHog3YhlGyUODdIqj5nNPNZDac1zZpV+7G4GuIVMevHqGM9
K6DZn5Nzo7itHQDwVZhb1aWADN0D7uhibYnvhOpgVonwHCLXqf/JrGiX21ywm//o
2ieB55xGAhkx/V0vRqGKNjWF68zv1ce9tWxQQ7IyeB1/beMjNTotSPqNaW+iJr3U
AZvk8/V2rMbp0VWS49i73WnEaBHI2KgzFB3xSFGoEAo7g+ynR/wOknVkBsWCT2Uy
b+jgXxZRzqVHJcBjC9kF2SCGneqkYkZqHD5vPF8paa1ryW41xEClPLsRBeSF1+si
hnT7R0kt0/Pj0EW0y6l8bNo6x/BkW99Y73xY2xwjhjJ9kHqdunpekghrd+Is8HNH
XRGrFijRsU1MGICVxj+hOjn6etFQYNrzbhl7WCn+UZxftPCv8anwmUn//TyOqKE7
MsxYAt5Hf8az4vvlUVoBqTgCoCF5ilt7am/871STYTyvsiOIIMFoFcsyMV0RAmWd
UtaTtHzJ5wMde4SsYrY=
=HTUH
-----END PGP SIGNATURE-----

Control: reopen -1
Apparently the issue is not fixed here.

Where one can see xrdp logfile, and maybe debug logging?
I'd enable these before running xfreerdp test against xrdp.

Thanks,

/mjt

The problem here is, on the xrrdp side:

[2026-07-09T21:01:39.699+0300] [INFO ] Client requested security types (RDP assumed) : SSL
[2026-07-09T21:01:39.700+0300] [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file:
[/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem]


By default, xrdp installs /etc/xrdp/key.pem as a symlink to
/etc/ssl/private/ssl-cert-snakeoil.key.  But this file is
unreadable by the user xrdp running as (xrdp:xrdp).  So
xrdp can't read its tls key, and fails.

It fails not just with freerdp testsuite. It fails *all* the
time, for any tls connection, by default.

I dunno how this prob should be solved properly.  But currently,
xrdp is unusable with default settings.

Thanks,

/mjt

Control: notfound -1 3.26.0+dfsg-1
Control: reassign -1 xrdp
Control: found -1 0.10.6-1
Control: affects -1 freerdp3

Thanks for your analysis. Reassigning this bug accordingly.

Sven

Control: retitle -1 by default, xrdp can't read its tls key; tls connections always fail

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132570#15

enabled by default.

Also see this patch in xrdp:
https://sources.debian.org/src/xrdp/0.10.6.1-2/debian/patches/document-certs.diff

I can reproduce it here, the patch just adds a comment to the config file:

```
 ; X.509 certificate and private key
 ; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out
cert.pem -days 365
+; note this needs the user xrdp to be a member of the ssl-cert group,
do with e.g.
+;$ sudo adduser xrdp ssl-cert
 certificate=
 key_file=
```

So my understanding is that TLS connection doesn't work by default, it
needs manual configuration. But it's not new, the patch is from 2020, in
order to address https://bugs.debian.org/860890 that was opened in 2017.

Like everyone, I don't know hot to solve it properly, I don't even use
xrdp myself...

Best,

On Wed, 15 Jul 2026 15:39:48 +0700 Arnaud Rebillout <arnaudr@kali.org> wrote:

Ok, so the breakage is a bit more subtle. The default xrdp.ini value for
security_layer is 'negotiate', meaning that if it can't use 'tls', it
falls back to 'rdp'. And so far, as we said, out of the box tls didn't
work, so rdp was used.

However it seems that a recent change in freerdp makes it more strict
with crypto, and so 'rdp' security layer isn't accepted anymore.

This is dicussed upstream:

- https://github.com/neutrinolabs/xrdp/issues/3808

Leading to:

- https://github.com/FreeRDP/FreeRDP/pull/12811

Quoting from the freerdp link above:
encryption method uses 3DES which is no longer approved in the OpenSSL
3.4 FIPS provider. On these versions, RDP Security is disabled so only
NLA/TLS (using AES) is negotiated.

So it seems that the right thing to to is to fix tls support in xrdp.
That could be achieved with this addition in the postinst:

    adduser xrdp ssl-cert

But is it the right thing to do? Can anyone comment on that?

I did a quick search on codesearch.debian.net, found something similar
done in postgresql-common and tryton-server.

Feedback from developers who understand that stuff better than me is
more than welcome!

Thanks,

Control: severity -1 important

I don't use xrdp myself (used it some 15 years ago, but not anymore).
So my wording was not accurate, - by default xrdp is not usable in TLS
mode.  There are some initial provisions to make it work - like pointing
to the snakeoil certs in the default config file, - but it doesn't work.

To complicate things more, it's kinda difficult to find the actual errors,
and the failure as seen "from outside" is definitely not clear.

Meanwhile, I reverted the change on the freerdp side which explicitly
enabled TLS.  So this bug report was actually due to the change in freerdp,
but the original issue is in xrdp.  So I guess severity of this bug can
now be lowered at least to "important" level (doing this now).

Oh wow.

Maybe we can add another system group, like ssl-snakeoil, and use it
just for this snakeoil cert? :)  Indeed, making xrdp part of regular
ssl-cert group feels wrong.

Fun stuff..

Thanks,

/mjt

Doesn't seem to work though.

Host-side, I'm running up-to-date Debian unstable, with freerdp3
3.29.0+dfsg-1 and remmina 1.4.43+dfsg-1. Guest-side, I have a Kali VM
(roughly equivalent to Debian testing) with xrdp 0.10.6.1-2+kali1
(equivalent to what's currently in Debian unstable).

Connection from remmina to the VM fails, with these errors:

```

[ERROR] MAC checksum error for non-FIPS PDU
[ERROR] xrdp_rdp_recv: xrdp_sec_recv failed
[ERROR] libxrdp_process_data: xrdp_rdp_recv failed
[ERROR] xrdp_process_data_in: xrdp_process_loop failed
```

So these seems to be caused by the fact that freerdp now refuses the old
"rdp" security layer (cf. my previous message in this bug for references).

If I fix TLS on the guest (with "adduser xrdp ssl-cert"), it works.

Best,

Arnaud

debci tests passed for freerdp 3.29 (where I disabled TLS).

I can probably do that in the freerdp test.  Also increase verbosity level
and print logs produced by xrdp - to see what's actually going on on its
side (the test currently fails on loong64 and I've no idea why).

Thanks,

/mjt

Hi Michael,
Hi Arnaud,

Thank you for your comments in this bug.

My toughts are the following:

I wonder what's the purpose of the ssl-cert group if it feels wrong to
add a system user to that group. If this is definitely a no-go, copying
the snackoil key to /etc/xrdp/key.pem could help. Though, this seems a
somewhat hack-ish approach. Otherwise, it seems pointless that xrdp's
postinst script generates snackoil cert and key at all.

A different approach would be to use debconf [1] to query the desired
base configuration from the person installing xrdp in case there is no
sane default configuration possible. Downside is the considerable
amount of work implementing this would cause to the maintainer.

All in all, xrdp should come with a working initial configuration.

Best,
Sven

[1] https://packages.debian.org/unstable/debconf