* Steffen Nurpmeso:
> > * Steffen Nurpmeso:
> > > I think it is common that S/MIME and SSL certificates are delivered
> > > via PKCS12, including the private key. You then seem to extract the
> > > individual things [...]
> >
> > Nope, that is the wrong way round. [...]
>
> Ok, but that is
Hello,
sorry for the late reply.
Ralph Seichter wrote in <87pninuqns@wedjat.horus-it.com>:
|* Steffen Nurpmeso:
|> I think it is common that S/MIME and SSL certificates are delivered
|> via PKCS12, including the private key. You then seem to extract the
|> individual things [...]
|
P.S.:
Steffen Nurpmeso wrote in <20191023224323.kaodd%stef...@sdaoden.eu>:
...
||> I think it is common that S/MIME and SSL certificates are
||> delivered via PKCS12, including the private key. You then seem to
||> extract the individual things like
||
||I think this is a severe security
Hello,
please excuse the late reply.
Uwe Brauer via Gnupg-users wrote in <874kzz1var@mat.ucm.es>:
|> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR\
|> >:
|>|On Sunday 20 October 2019 at 3:20:41 PM, in
|>|, Uwe Brauer via Gnupg-users wrote:-
|>|
|>|> I just
* Steffen Nurpmeso:
> I think it is common that S/MIME and SSL certificates are delivered
> via PKCS12, including the private key. You then seem to extract the
> individual things [...]
Nope, that is the wrong way round. The correct sequence to obtain an
S/MIME certificate is as follows:
1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello!
Mikhail Morfikov wrote:
> Let's assume you are right, and it's because of the way the
> linux works.
>
> When I clear the conntrack table, the following messages appear
[...]
> So it's an ACK packet (possibly one per already opened
>
Let's assume you are right, and it's because of the way the linux works.
When I clear the conntrack table, the following messages appear in the FW log
(I don't block the gpg packets for now, just log and accept them in its rule):
Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Mikhail,
What follows is an educated guess, but only a guess...
Mikhail Morfikov via Gnupg-users wrote:
> gpg wants to connect to the network, but it looks like it wants
> also TCP/993 (IMAPS). This happens when I use Thunderbird as a
> mail
> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR>:
> |On Sunday 20 October 2019 at 3:20:41 PM, in
> |, Uwe Brauer via Gnupg-users wrote:-
> |
> |> I just found that
> |> https://extrassl.actalis.it/portal/uapub/doProcess
> |
> |> Provides a
> Hi
> On Sunday 20 October 2019 at 3:20:41 PM, in
> , Uwe Brauer via Gnupg-users wrote:-
> [...]
> I'm no expert but their Certificate Policy reads to me that the
> private key is compromised right from the start. I think usually the
> keys are generated on the subscriber's device and only
On 22.10.2019 20:50, Werner Koch via Gnupg-users wrote:
> There is no real reason
> for this and we could change the license if that really makes a
> difference for you.
It would help me as a downstream packager at least; to the extent that
otherwise we'll have to update license acceptance
I'm filtering OUTPUT traffic on my Debian via
nftables+cgroups(net_cls)+cgrulesengd, and all apps, which want to connect to
the network, I have to assign some cgroups class and add a rule in the FW.
The gpg binary wants TCP/443 to speak with keyservers (optionally TCP/80).
I thought that's all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello GnuPG users!
Background: I'm working a bit on Mailpile's Autocrypt support
these days. Mailpile creates OpenPGP keys for its users, which
are protected by a strong passphrase, but generally manages those
passphrases on the user's behalf to
13 matches
Mail list logo
